STM32F4-SKR-Pro-V1_2 Compile Error

[landtree]

Hello All,

I have been banging my head at this for awhile now.

I am using VsCode/PlatformIO, and used the web configurator to set up my files. Change my environment to STM32F4-SKR-Pro-V1_2

I am using TMC drivers and the folder is in the Modules folder. If that makes any difference.

When I go to compile, I get this error:
compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal.c.o
Compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal_adc.c.o
Compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal_adc_ex.c.o
Compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal_can.c.o
Compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal_cec.c.o
Compiling .pio\build\STM32F4-SKR-Pro-V1_2\SrcWrapper\src\HAL\stm32yyxx_hal_comp.c.o
: fatal error: variant_BLACK_F407ZX.h: No such file or directory

I am not sure what to change at this point.

[Paciente8159]

Hi there. I'm AFK. As soon as I get the chance to test I'll give some feedback. Did you configured manually or used the web builder.
If you used the web builder please share the config files

[landtree]

Take your time! Thank you for the help. Here are my files from the web builder:

ucnc_build.json
boardmap_reset.txt
boardmap_overrides.txt
cnc_hal_reset.txt
cnc_hal_overrides.txt

[landtree]

Follow up!

I ended up nuking my platformio and forced it to rebuild my platform files. I now have a new problem :)

Thank you!

[Paciente8159]

Mine compiles fine.

Maybe you have a broken cached files or broken framework.
Open a PlatformIO: New Terminal an type this command
pio pkg list -eSTM32F4-SKR-Pro-V1_2

This is my output:

[Paciente8159]

Again thanks for trying this. Another culprit for this kind of problem would be an incorrect offset for the vector table.
I tried to compile adding these option -DHSE_VALUE=8000000 -DVECT_TAB_BASE_ADDRESS=0x08000000 -DVECT_TAB_OFFSET=0x8000

This got me a bunch of warning: "VECT_TAB_OFFSET" redefined
I assumed the PIO configuration board_build.offset = 0x8000 would take care of this.

Out of curiosity I built the project enabling verbose and I got this:

arm-none-eabi-gcc -o .pio\build\STM32F4-SKR-Pro-V1_2\FrameworkArduinoVariant\generic_clock.c.o -c -std=gnu99 -std=gnu17 -Wall -fdata-sections -ffunction-sections -fno-exceptions -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -Os -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -DPLATFORMIO=60115 -DSTM32F4 -DSTM32F407xx -DSTM32F40_41xxx -DHAL_TIM_MODULE_DISABLED -DHAL_EXTI_MODULE_DISABLED -DHAL_UART_MODULE_ONLY -DBOARD=BOARD_SKR_PRO_V1_2 -DHSE_VALUE=8000000 -DVECT_TAB_BASE_ADDRESS=0x08000000 -DVECT_TAB_OFFSET=0x8000 -DSTM32F4xx -DARDUINO=10808 -DARDUINO_ARCH_STM32 -DNDEBUG -DARDUINO_BLACK_F407ZG -DBOARD_NAME=\"BLACK_F407ZG\" -DHAL_UART_MODULE_ENABLED -DUSE_FULL_LL_DRIVER -DVARIANT_H=\"variant_BLACK_F407ZX.h\" -DCUSTOM_PERIPHERAL_PINS -DVECT_TAB_OFFSET=0x0 ....(continues)

At the very end of this VECT_TAB_OFFSET is being redefined to offset 0. This means that on boot the main application is most probably just running the bootloader again instead of jumping to the offset address and running the main.
I will see what alternatives I have to go around this. I believe the firmware is being written in the correct offset. Just the vector table is being pointed at the wrong place.

[Paciente8159]

After some digging I discovered the issue with the vector table.

It seems Marlin (from which I based my configurations is locked to version 12.1 I believe. So this was the way to set the offset:
board_build.offset = 0x8000

I did not locked the framework version so it uses the latest stable (currently 17.5). This was modified in December/2023 to this:
board_build.flash_offset = 0x8000

this is again one warning bell that I need to lock framework versions to prevent these type of issues.

If you want to give a last try at it, please modify the SKR Pro PIO settings to this

[env:STM32F4-SKR-Pro-V1_2]
extends = common_stm32
board = black_f407zg
board_build.flash_offset = 0x8000
board_build.f_cpu = 168000000L
board_upload.offset_address = 0x08008000
board_upload.maximum_ram_size = 196608
board_upload.maximum_size = 1048576
build_flags = ${common_stm32.build_flags} -D BOARD=BOARD_SKR_PRO_V1_2 -D HSE_VALUE=8000000

[landtree]

Sadly, there is still nothing. Here is what I did: I fully cleaned, uninstalled, and reinstalled the libraries, just in case. I am still using the default config from the webbuilder for the SKR 1.2. I added the above code to the stm32.ini and replaced the old code.

I manually ran the build to get the verbose output as you might see something useful in that.
OUTPUT.txt

[Paciente8159]

Oh man I was really hoping this was the issue.
Apart from your output being unusually small (I assume you omitted all the middle stuff) I can see that the vector table is now correct

.isr_vector 392 134250496 => this is address 0x08008000 the correct position

I guess I really have to check how this goes when I get the MKS board in my hands and try to flash it.
Again many thanks for all your tests.

[landtree]

Here is the full output incase you want to see it.
OUTPUT.txt

[Paciente8159]

I've created #726 to address this issue.
As soon as I can confirm this solves the issue I'll push it.
Again thanks for reporting this and the tests.

[Paciente8159]

Better yet. Try this binary.
firmware.zip

[landtree]

I will send you an update in the morning!

[landtree]

I seem to have to continue to be the harbinger of bad news. With that firmware file I still don't have anything.

[landtree]

I don't know if this is useful, but I borrowed an ST-Link v2 from my friend.

I haven't done anything other than connect to it via the stlink utility and sit and stare at it.

[Paciente8159]

Can you scroll down to see a bit above address 0x08008000?
A couple of lines beforw that address should also be visible.

Thanks

[landtree]

Let me know if you want any other screenshots.

[Paciente8159]

Awesome. Can you show me a 4 or 5 line above address 0x08008000?

EDIT
I can tell right now that signature does not look correct.

[landtree]

[Paciente8159]

@landtree can you please try and change the stm32.ini file board variant for the skr pro from

board = black_f407zg

To

board = black_f407vg

[landtree]

@Paciente8159 Adjusted and no LED or USB

[Paciente8159]

In that case there is only one test left to do. It's to add my custom linker script template.
I'll first try it on my board and I'll let you know.

[Paciente8159]

@landtree please try to download #738 again and upload the firmware.
I added a custom linker script and a complete new startup code.

My only question if this works is what implications this might have if one module uses Arduino libraries that depend on hardware.
But since most or all modules are Arduino independent the risk of it is minimal.

[landtree]

That did the trick. I was able to build from a clean download and can connect over USB and have the blinking LED.

No configs, just the base firmware.

[Paciente8159]

Awesome.
Tomorrow I will try to fine tune that configuration.
I may need for you to test it on your board if you don't mind.

Huge thank you for all your testing and patience.

[Paciente8159]

I reverted the changes. Can you retry now?

[landtree]

This build works. USB & Activity LED.

[Paciente8159]

That is very intriguing.
Something in the linkerscript file then I assume.
I'll keep this version and investigate.

Thanks for all the tests and help.

[landtree]

No problem! I will try using a config file in a little bit to see if anything explodes! I will let you know if I run into any problems.

[landtree]

@Paciente8159 I just did a quick test with the config files. Other than some tweaks to have the correct step direction & speed, it seems like a functional build!

Thanks again!