Binary Flashing the STM32

[codex653]

So currently I am working on a test bench for a system I am designing around the STM32F7 series of chips. The idea is to use python to load pre-built binaries from custom VGDB projects with this tool and then run all my tests using a combination of the google test framework and some stuff done on my PC. What I am hoping to get some clarification on what exactly is the proper way of flashing the raw binary that is output from the build cmd inside of a VGDB project.

For example, I see that when flashing with VGDB, the output window will read something similar to:
<pre class=”a-b-r-La”>Info : device id = 0x10016451
Info : flash size = 2048kbytes
Info : Single Bank 2048 kiB STM32F76x/77x found
flash_bank_summary:0x8000000|0x200000|stm32f7x.flash
FLASH progress reporting is now on

target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Erasing FLASH: 0x08000000-0x08018000…
Info : Programming FLASH (6 sections, 89256 bytes)…
Info : Programming FLASH section 1/6 (504 bytes) at 0x08000000…
Info : Padding image section 0 with 8 bytes
Info : Padding image section 1 with 2 bytes
Info : Padding image section 2 with 2 bytes
Info : Padding image section 3 with 1 bytes
Info : Padding image section 4 with 3 bytes
Info : flash_write_start:0x8000000|0x8015cb8|stm32f7x.flash
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0xfffffffc
Info : flash_write_done:stm32f7x.flash
 

This leads me to the conclusion that the main program actually is loaded to 0x80000000 and there is a smaller something (some startup code maybe?) pushed to 0x08000000. Is this right?

My problem I have been having with the python flashing tool is that it only writes the binary as a single blob. Erasing the whole chip and then writing the binary starting at 0x08000000 OR 0x80000000 does not work. Instead, I’ve found that I have to write the same binary to 0x08000000 AND 0x80000000 and then it will work fine…which can’t be right…

 

Is there a resource somewhere for how VGDB generates the binaries and how to properly flash them? I’m not sure I quite understand how everything is supposed to be mapped.

[support]

Hi,

Yes, as long as you have the “Generate Binary file” enabled in VisualGDB Project Properties (or VS Project Properties for MSBuild-based projects), VisualGDB should generate .bin files that can be simply programmed to the FLASH memory (offset 0 from the beginning of FLASH).

[codex653]

Ok that is what I thought. Is there a way to check if that setting is enabled after the project is created? I went looking through my project settings and didn’t see anything explicitly labeled for generating/not generating the binary. I know that is an option during set up.

[support]

Hi,

Yes, please let us know your project type (MSBuild or GNU Make) and we can point to the specific location of this setting.

[codex653]

It’s an MSBuild type.

[support]

Hi,

Thanks for confirming this. For MSBuild projects the setting should be under VS Project Properties (not VisualGDB Project Properties) -> Embedded Project -> Generate Binary File.

[codex653]

Wow ok, somehow I missed that… Whoops.

So I’ve tried flashing to 0x00000000 and the raw binary doesn’t seem to be working after reset. I don’t have the VGDB profiler or stub init functions so I don’t think it’s waiting to connect to the PC. Again, the only way I’ve been able to get the binary to work is that weird method described previously.

• This reply was modified 5 years, 11 months ago by codex653.

[support]

Hi,

Please try attaching to your device as shown in this tutorial. It should show what exactly the CPU is doing. Please also use the “Verify memory” button in the GDB Session window to check whether the FLASH memory was programmed correctly.

[codex653]

Interesting. I didn’t know I could do that. I’ll go through the tutorial and see if that doesn’t help me figure out what’s going on. Thanks!

[Author]

Posts