STM32F777 - unable to run code when flashed using jlink/bootloader

[Podkovirin.Anton]

Posted on November 15, 2017 at 15:42

A short background:

I have a custom board with two STM32F777 uC on it. The goal is to program one using the other. I'll refer to the one that programs master and the one that being programmed, slave.

The master runs from flash in dual bank/boot mode and has a dedicated jtag connection for debugging.

The slave runs

from flash 

in the default single bank mode, it is supposed to be programmed by the master using the internal bootloader and a UART connection. It also has a jtag connection for debugging.

While being able to program and run code on the master using IAR debugging, J-Link and self programming, I'm having issues running code on the slave using part of the methods:

- When debugging through IAR using a j-link, I'm able to load and run code successfully. Also, after resetting the board, the code on the slave uC runs without any issues.

- When trying to program using J-Flash, It seemingly programs it correctly, but nothing happens when I try to run the GO command or when I power cycle the board.

- When trying to program using the bootloader, I'm able to go through the entire process of programming the slave uC (Connect to the bootloader through UART and receive all the expected Acks/nacks), but when I send the go command/trigger the reset line, the code doesn't run on the slave uC. When I read back the data from the memory using J-Flash, it seems to match the binary exactly, but it doesn't run. 

Based on the bootloader flowchart, it seems that protection level 2 should be active for the bootloader to jump to 0x08000000. I wrote a script to lock the slave after programming with J-Flash, but it didn't seem to work, except for locking me out of the uC.

It seems like I'm doing something wrong with the Option Bytes in single bank mode, but I'm not sure what it is.

Has anyone else tried to program the STM32F777 using J-Flash and has issues?

#j-link #stm32f777 #usart-bootloader

[Tesla DeLorean]

Posted on November 15, 2017 at 16:43

>>

I have a custom board

 ...

Is the BOOT0 pin pulled low? Or left floating?

[Podkovirin.Anton]

Posted on November 15, 2017 at 16:47

It's pulled low

[Tesla DeLorean]

Posted on November 15, 2017 at 19:19

The system loader might have the watchdog running.

>>..

code doesn't run..

You'll probably need to instrument things and add check points, starting in Reset_Handler to see if it arrives there and gets stuck deeper in the code. These will need to use GPIO or USART so as to avoid interference with the debugger. Watch for infinite loops or Error_Handler() type nonsense where things can get stuck and die, giving the appearance of 'doesn't run'. If you are turning on HSE, and bringing up the PLL, try remarking out all that code and let things run nominally off the HSI.

[Podkovirin.Anton]

Posted on November 15, 2017 at 20:25

Thanks, Clive, I'll try adding some indicators in these handlers.

Why would the watchdog be configured differently when programming the same binary?!

In IAR it works not only in debug mode, but also if I reset the system afterwards. As i understand, that means that in both cases the execution should start the same way after reset.

[Podkovirin.Anton]

Posted on December 12, 2017 at 23:00

Came to update in case someone else gets into this tricky weird (probably unlikely) situation.

The problem was in generating the binary that i was trying to flash. Somehow the name of the linker output file got the '.bin' extension and ended up being called same as the raw binary. Each time we were generating the binary, the linker output was overwriting it. So i was just flashing the wrong thing.