cancel
Showing results for 
Search instead for 
Did you mean: 

Coustom bootloader dosent start the application when power is turned off and turned on

RRC
Associate II

We have custom bootloader that jumps to application when i switch off power and switch on power the bootloader dosent jump ton application , so again inned to upload Application to it

4 REPLIES 4
TThan
Associate III

Hi RRC,

may I ask you to elaborate a bit more about your issue? From the information you gave it is very difficult, if not impossible, to give you any help.

I have some experience with custom bootloaders an STM32 microcontrollers, so I know that it is possible.

When you say you have to upload the application again, you mean that you start the application from your IDE again? In that case the program counter will most likely be set to your application and started directly from there. Or is the custom bootloader overwritten in that case?

Most likely issures causing such problems are:

  • Linker file issues
  • Stakpoint of app not set correctly in bootloader
  • Missing interrupt enables in app or too much enables interrupts from bootloader when app gets calles
  • Wrong app entry point called by bootloader
  • Peripehals still enabled from bootloader that are not handled in the app or could not be simply reconfigured in app before deinitializing them properly.
  • ...

Did you try to debug the firmware start from bootloader in the Disassembly view instruction by instrucion?

Maybe the app gets stuck in the Hardfault Handler or an unhandled interrupt? Just guessing here.

Regards

Thomas

RRC
Associate II

Yes Thomas as you said i upload a code from IDE , Actually what happans once the Application code upload with ide it works good both Bootloader and application code too But when I remove power and plug in the application code and bootloader code both are there in memroy ,As i want as device get the power it need to jump to application from bootloader as in case do you have any solution ,

No linker file issue it works fine

I dont understand the reamaning points can you tell about more

Make sure BOOT0is pulled LOW​

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
TThan
Associate III

The hint from Tesla DeLorean is valid, indeed. You should definitely check that BOOT0 pin is actively pulled low and not left floating.

When you say start from IDE is working, how do you know that you bootloader is operating? At least to my understanding the bootloader and the app are two different projects that are flashed separately and reside in separate flash pages. But maybe I do have a general missunderstanding of what the term "bootloader" means? Sorry, if that is the case.

Please let me explain what I understand when the term "bootloader" is used.

For example the bootloader resides in FLASH pages 0-3 (0x08000000 - 0x080017FF) then main application starts at address 0x08001800 and uses the remaining FLASH:

So when you start only the app from the IDE, the bootloader will not net invoked since the app starts directly from the reset vector given at 0x08001804, at least the debugger / flash loader in the IDEs I know work this way.

Are you sure, the bootloader is still in FLASH after your application gets programmed by the IDE? Some IDEs do a FLASH mass erase when programming a new application. Such a mass erase will erase your bootloader, too.

But on power up, the bootloader start from the reset vector at 0x08000004 and wants to start the app. So to debug what the bootloader is doing when the app gets started, I usually follow these steps:

  • Program bootloader and the application both to the FLASH of the microcontroller.
  • Open the bootloader project and create a debug configuration that either erases only the FLASH pages where the bootloader resides (no mass erase of FLASH, or teh application is gone) or it does not program the bootloader at all, since it is already pre-programmed.
  • Now debug the bootloader using this special configuration and let it run just before until the call to the application will be executed.
  • Switch the debugger to Dissasembly view und instruction stepping and step through the instructions when the application gets called step by step.
  • Now you can see exactly what happens when your application gets called by the bootloader and were it goes wrong.

But all this discussion is a bit difficult. It will be much easier if we would know the following:

  • which IDE / Toolchain are you using?
  • Which STM32 derivate are you using?
  • Can you share you bootloader code, or at least the part the calls the application?

Best Regards

Thomas