openocd + stm32f4 flash issue

Question

I am working on our company’s custom stm32f429 board which is fairly complicated with multiple peripherals. Till today morning the board worked fine with no issues. Once i shifted the board from the test bench to inside the robot (connected to a battery). It stopped responding well to openocd and gdb commands. I have debugged all possible electronic issues and no new parts have been added to the board recently (just to rule out the possibility of interference). Other boards working off the same power rail do not exhibit such issues. I replaced the chip twice to no avail. ST-link utility works fine as well. Following is the output of openocd telnet session:

command: reset halt
 "target state: halted
 target halted due to debug-request, current mode: Thread
 xPSR: 0x01000000 pc: 0x1fff5162 msp: 0x20002d40
 "

As you can see the program counter does not reset to its intended location i.e. "0x08000200" and the msp points to the wrong address as well: 0x20002d40 instead of 0x20003000.

Following is the output of "flash write_image erase "

flash write_image erase /home/talha/Seven_LLS_experimental/build/F429/src/stm32_uavcan/stm32_uavcan.hex
auto erase enabled
Padding image section 0 with 12 bytes
Padding image section 1 with 4 bytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000042 msp: 0x20002d40
wrote 262144 bytes from file /home/talha/Seven_LLS_experimental/build/F429/src/stm32_uavcan/stm32_uavcan.hex in 7.289705s (35.118 KiB/s)

The program counter and msp point to the wrong address again. I have checked if there is any issue with the linker script or my code but the code runs flawlessly on the eval board.

I want to know if someone here has experienced a similar issue before? I strongly believe that this is a HW issue and i’ll have to perhaps solder a new board cry, but before i put in the effort i just want to ensure that there isnt anything else that i could try

• old_timer: you sure this isnt the code openocd downloads and runs in order to facilitate the flash write?
• old_timer: for the 0x1ffff... pc value that is because you are running the bootloader when you halted. check your boot0 pin. or it is as Turbo J says that the bootloader always starts.
• old_timer: just do a reset not a reset halt, then let it run for a bit then halt. try an infinite loop program to test the tools/board/chip, a few lines of asm that have a vector table and a branch to self. flash, reset, halt, and then examine these values.

Answer 1

As you can see the program counter does not reset to its intended location i.e. "0x08000200"

Your understanding of this MCU is not correct. It does NOT start from the flash - it starts from the internal mask ROM at 0x1FFF0000. See refman page 71, for example.

The "reset halt" catches execution early in this ROM location - before checking boot pins and executing either bootloader or user program.

• Asusrog: Thank you for the response. So after doing what @old_timer suggested. The pc counter was basically stuck in the ROM memory and never advanced to the reset_handler. For now i have soldered a new board and its working fine. But i still dont know what caused it in the first place.