Building error on custom board using STM32G473QET6 MCU

doogie65 · September 12, 2023, 10:26am

I am building a project for a custom board using the MCU stated in title. I am setting it up with an arduino frame work, on setting up the project I have selected a nucleoboard using an MCU in the STM32G4 family.
My platfomio.ini file looks as follows:
inifile

My .json file for the custom board looks as follows:

I have duplicated a variants folder for my mcu from C:\Users\<users>\.platformio\packages\framework-arduinoststm32\variants. I replaced the linker script in the duplicated folder with one i produced from stm32cubemx for my MCU.

After doing all of this I am still unable to get a build and get these error messages :

I am quite new with all of this and am prone to making silly mistakes. If anyone could help it would be greatly appreciated.

maxgerhardt · September 12, 2023, 11:40am

The extra flags entry is missing a -. You want it to give it the compiler option -DSTM32G4xx.

maxgerhardt · September 12, 2023, 11:41am

Subsqeuently, the variant field is wrong. The “variant” has to be the relative path to the used variant within the variant folder of STM32Duino (https://github.com/stm32duino/Arduino_Core_STM32/tree/main/variants).

For your G473QET6, this is is the value STM32G4xx/G473Q(B-C-E)T_G474Q(B-C-E)T_G483QET_G484QET because of this.

doogie65 · September 12, 2023, 12:41pm

Thanks for getting back to me.
So I have updated my json file as follows:

I then attempted a build, the terminal started spitting out error after error and appeared to continue forever, so I terminated the build and took a screenshot of the errors. It appears it’s not accepting the stdint.h types :

Have you any idea why it’s doing this @maxgerhardt ?

maxgerhardt · September 12, 2023, 1:12pm

I think you may be missing the definition of the subseries macro, as is required by

github.com

stm32duino/Arduino_Core_STM32/blob/6c48d7384d5c1d40e4055083fc7af48c02c5ad71/system/Drivers/CMSIS/Device/ST/STM32G4xx/Include/stm32g4xx.h#L59-L72


      
          #if !defined (STM32G431xx) && !defined (STM32G441xx) && !defined (STM32G471xx) && \
              !defined (STM32G473xx) && !defined (STM32G474xx) && !defined (STM32G484xx) && \
              !defined (STM32GBK1CB) && !defined (STM32G491xx) && !defined (STM32G4A1xx)
            /* #define STM32G431xx */   /*!< STM32G431xx Devices */
            /* #define STM32G441xx */   /*!< STM32G441xx Devices */
            /* #define STM32G471xx */   /*!< STM32G471xx Devices */
            /* #define STM32G473xx */   /*!< STM32G473xx Devices */
            /* #define STM32G483xx */   /*!< STM32G483xx Devices */
            /* #define STM32G474xx */   /*!< STM32G474xx Devices */
            /* #define STM32G484xx */   /*!< STM32G484xx Devices */
            /* #define STM32G491xx */   /*!< STM32G491xx Devices */
            /* #define STM32G4A1xx */   /*!< STM32G4A1xx Devices */
            /* #define STM32GBK1CB */   /*!< STM32GBK1CB Devices */
          #endif

So just change the extra_flags value to be

-DSTM32G4xx -DSTM32G473xx

doogie65 · September 12, 2023, 1:22pm

That did the trick. The project builds and I can upload now, however I am now getting an error for the include <Arduino.h> and nothing happens when I upload a simple blinky program onto my board. I’m assuming that is because of the include error.

maxgerhardt · September 12, 2023, 1:25pm

If the project builds, it must have found Arduino.h and it’s just the VSCode intellisense lagging behind.

Trigger a rebuild of the intellisense in the easiest possible way: Ctrl+Shift+P → Reload Window (or “Rebuild Intellisense Index”).

The code looks good for PB6. It should also hit the clock init code for HSI + PLL (so no external quartz crystal is assumed) here.

After the window has reloaded per above, and given you’re uploading via ST-Link, you should be able to debug the project. Set a breakpoint in your setup() and loop() function then use the debugging sidebar → Play button on “PIO Debug”. Does it hit the breakpoint in setup? If not, press the “pause” button and see where it is stuck in the backtrace.

doogie65 · September 12, 2023, 2:46pm

Okay I have reloaded VSCode and rebuilt and uploaded the project, added the breakpoints in and started the debugger. Like I said before, this is all new to me so I’m struggling to interpret whats going on.
The start up file is opened once the program stars debugging at line 62 as follows:

I’m not too sure where to go from here so I will share with you the debuggere console, nothing is happening on my board in regards to the blinky program.

Apologies if I haven’t done what you have asked, I’m a bit unsure if it’s hitting the breakpoint or not but I don’t think it is, how do i check where it is on the backtrace?

maxgerhardt · September 12, 2023, 6:23pm

Well… The firmware is usually loaded in flash, which in the microcontroller’s memory map is at 0x8000000. But the debugger shows you that the halt address is 0x1fff3b0c. This memory addresss (area) indicates that the chip is executing the builtin bootloader code. See https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf page 36,

as well as the reference manual https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf page 82

grafik

And see https://community.st.com/t5/stm32-mcus-products/getting-stuck-at-memory-address-0x1fff-5064-on-boot/td-p/103603.

The microcontroller uses the state of the BOOT0 and BOOT1 pins to decide when to jump to this bootloader code. Per the linked PDF, both these pins should be connected to GND (e.g. directly or via a pulldown resistor) if you want the chip to execute the uploaded firmware (0x8000000) instead of the bootloader code.

What does that look like on your custom board? Hopefully you didn’t leave these pins unconnected or hard-connected to +3.3V?

doogie65 · September 13, 2023, 7:21am

Thank you, that was the issue, everything working, now, I can’t thank you enough!