STM32F303VCT - Applicatoin code not running outside of STMCubeIDE.

[jlag]

STM32F303 - Application running fine in CubeIDE debugger, custom board. It will not start as standalone, programmed with CubeIDE or CubeProgrammer with .elf or .hex.

I have created an 'attach' run debug configuration, which can successfully display program execution and symbols when connected after CubeIDE starts the application.

I have placed the following code in main() in order to pause execution at the top of main to hopefully attach and step through to identify the fault.

However, when I attach after a cold/power reset, this is my trace, as if the system is not making it to main after cold start/no debugger.

I see the following data in the flash at location 0x0000 0000 when read with CubeProgrammer:

Shouldn't 0x04-0x07 contain the program start address of 0x0800 0000 + vector table size?

Is the flash is read protected and I am looking at invalid data?

[AScha.3]

Hi,

what is state of boot0 pin , gnd ?

(0x1ffffxxx looks like jump to system/bootloader...)

[jlag]

Yes @AScha.3, it is 0V/Gnd via 10K Ohms.

[TDK]

Examine option bytes which might be hard-wiring it to start into the system bootloader.

AN2606 will list all possible patterns which can cause it to run the bootloader rather than system flash. Certainly seems like you're in there, so might be worth running through all possible scenarios.

Debugging circumvents normal startup behavior.

[AScha.3 · Accepted solution]

from F303 rm.

Solder boot0 to gnd.

Then flash F303 with your program, use cubeProgrammer , and verify the flash start address. (0x08000000 )

[jlag]

@TDK - Thank you for the information. I have been looking through 2606 document and became a bit confused. The only reference to the STM32F3xxx in Table 3 states that bootloader ID is 0x50 @ 0x1FFF F796:

Yet, reading the flash at that address, reveals 0x41 as the ID:

which from the table relates to different STM32 devices than the device that is connected:

I am supposing that the flash doesn't lie, but it seems inconsistent to the documentation.

EDIT: Update: the 0x41 is correct after opening my eyes a bit:

It seems I am most interested in the nBOOT1 option byte, as I have electrical control of BOOT0.

From RM0316 for STM32F303 it states that the Option Byte register (FLASH_OBR) is located at offset 0x1C. Offset from where I cannot seem to figure out:

Currently, the bootloader is not in scope of the project. What is in scope is testing the HW, so I am looking for the fastest way to get the device to boot standalone in order to accelerate testing, programming either with the booter or an STMLINK V3MINIE via SWD.

[jlag]

@AScha.3 - Thanks, I was incorrect RE the BOOT0 resistor:

I have verified logic low on the Boot0 input. I am not sure soldering to GND will make any difference here.

[TDK]

Use STM32CubeProgrammer to view the option bytes. When connected, select the OB tab on the left.

The offset is from 0x40022000 as seen here:

[jlag]

Hi @TDK - I tried reading those addresses, and when I did, the programmer yelled at me, and said the "read failed".

But, it looks like I may have a BOOT0 problem as I think the BOOT0 (J5) switch is rotated mechanically on the board and seems BOOT0 is high on this particular board. I am removing it now to verify 0V on BOOT0. Kudos to @AScha.3 for the insight to look into this.

[jlag]

It turned out to be a HW issue that @AScha.3  made me investigate further. The switch on the board for BOOT0 high/low was mounted incorrectly and caused BOOT0 to be logic 1 for this particular board.

There was no other electrical way to get BOOT0 to logic 0 other than removing the BOOT0 selection switch from the PCB:

Bye bye switchie:

Removed boot selection switch from the PCB and all is well. I was thinking this was way worse than it was (clock chasing, etc.).

KUDOS to @TDK for all their help as well. Learned quite a bit about the STM32 ROM booter. I do still feel the documentation and tools regarding boot specifics (option bytes, write only, what is available for particular uPs in the CubeProgrammer) for particular STM32 uPs are a bit obtuse. Kudos to the community, 2 for 2 on helping me in the STM32F303 "bring-up" world.