Joshua Kay

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

7 years, 2 months ago.

NUCLEO F767ZI Custom Bootloader Problem

Hi,

I am running into problems with the design of a custom bootloader for the STM32F767ZI micro-controller. I am prototyping this bootloader with the NUCLEO F767ZI development board. I have followed the instructions at https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/bootloader/ on how to implement bootloaders into mbed projects. I have the bootloader working for a few different micrco-controllers (LPC1768 and FRDM K64F.) However, I have problems with the NUCLEO F767ZI. I have verified I am writing the correct data into the correct flash registers. The issue occurs with the mbed_start_application function. I believe the program isn't jumping from the bootloader to the main application properly. I set mbed_app.json and modified the linker file and the target.json file similarly for each micro-controller. Despite this, the NUCLEO-F767ZI does not transition from the bootloader to the main application properly while the LPC1768 and FRDM K64F do operate properly.

To help debug this problem I created a test program with a "dumby" bootloader that merely would blink LED1 a few times and then enter the main application that would blink LED2 a few times. Therefore, this program was used to verify the jump from the bootloader to the main application was correct. This program was prepared very similarly to the mbed-os-example-bootloader-blinky program where the bootloader and the main application were loaded onto the target at the same time. The test program worked successfully on the LPC1768 and FRDM K64F targets but yielded odd results for the NUCLEO F767ZI target. When loaded on the target the first time, the bootloader would run and would attempt to jump to the main program and fail. When the same binary was loaded onto the target a second consecutive time, the target would skip the bootloader altogether and run the main application. When the same binary was loaded a third consecutive time, the target would run the bootloader again and then fail to run the main application as before. And this pattern would repeat.

Additionally, I ran into a problem where a newer commit of mbed-os used to compile a simple, tested blinky problem would not run on the NUCLEO-F767ZI target. Reverting back to an older commit fixed the problem and I could run mbed-os compiled programs on the NUCLEO-F767ZI. But I'm starting to get a feeling that mbed-os is a little buggy for the NUCLEO-F767ZI target. Are there any known bugs with mbed-os for the nUCLEO-F767ZI target that might explain some of this behavior?

Thanks, Josh

1 Answer

Jan Jongboom
7 years, 2 months ago.

Hi Josh,

I ran into a bug in the ISR powerdown implementation on another ST chip. Perhaps this will fix your issue too.

Otherwise GDB should be able to help you find out what goes wrong:

  1. Build with debug profile
  2. Load the whole application (incl. bootloader).
  3. Connect to the board over OpenOCD and attach GDB.
  4. Load the application in place, see where the application hangs.

My bet is that the jump is fine, but that the application insta-crashes.

Hi Jan,

I implemented the bug fix for the ISR powerdown, but I witnessed the same results. I still need to use GDB to debug the issue.

I actually didn't explain my issue correctly in my previous post. Here is a more accurate description of what is happening:

1) "Dummy bootloader" + simple application are loaded onto device. 2) When device is run, "dummy bootloader" blinks for a few seconds and then hangs when it tries to jump to simple application. 3) A soft reset (reset button) results in the "dummy bootloader" running again and hanging. 4) When the device is hard reset (power cycled), the simple application runs. 5) A soft or hard reset runs the simple application, not the bootloader. So the device is essentially stuck in the simple application. 6) Reloading the bootloader + application brings us back to to 1)

GDB will give me a better idea of where I am hanging, but I am curious if this behavior gives you anymore insight into the issue based on your knowledge of the build system or other reported bugs.

Thanks, Josh

posted by Joshua Kay 30 Aug 2017