0

I have splitted software into two parts: Bootloader(without RTX), Application image with RTX. But the bootloader could not load the application image with RTX. The Flash settings are:

--------------------------------------------------------------------
        start address       size
IROM 1: 0x08000000          0x2800   - Bootloader (without RTX)
IROM 2: 0x08002800          0xD000   - Application Image (with RTX)

I have test 3 ways: (1) Use another App without RTX. The bootloader could load the app successfully.

(2) Change the application with RTX project IROM setting. I change the application project IROM start address from 0x08002800 to 0x08000000. And I download the application image into flash from the address 0x08000000. Ihe image could run from 0x08000000 successfully.

(3) The application image IROM start address setting is 0x08002800. After downloading bootloader and app image into flash, I debug the app project in keil step by step. I found that there is a "osTimerthread stack overflow" error. Then the main thread stack is also overflowed. I have tried to increase the stack size, but it doesn't work. I found that the app starks in the RTX kernel switching. All threads are in the waiting state, and are not running.

Ps, when I am debugging in the keil,test item(2) also have stack overflow errors during kernel initialization. The item(2) works fine till now. So I just put any information needed here.

This is the debugging picture for item (3). enter image description here

artless noise
  • 21,212
  • 6
  • 68
  • 105
lrouter
  • 349
  • 1
  • 5
  • 20

1 Answers1

0

Are you actually changing the linker script to link starting at 0x08002800 when using the bootloader or just loading the application (linked at 0x08000000) at an offset of 0x2800? Double check this (look in the map file) for your linked output to ensure that all your symbols are not linked in the 0x08000000 - 0x08002800 range.

Additionally, make sure you are using the correct entry point and stack pointer. The application's stack pointer should be at 0x08002800, and the reset vector will be at 0x08002804. Your bootloader will need to setup the MSP register with the correct stack pointer before jumping to the application. Here is some example code from ST's USB DFU bootloader:

typedef  void (*pFunction)(void);
pFunction JumpToApplication;
uint32_t JumpAddress;

/* Jump to user application */
JumpAddress = *(__IO uint32_t*) (USBD_DFU_APP_DEFAULT_ADD + 4);
JumpToApplication = (pFunction) JumpAddress;

/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) USBD_DFU_APP_DEFAULT_ADD);
JumpToApplication();

Additionally, depending on how much your bootloader configures before jumping to the application, you may need to 'deconfigure' certain peripherals. As an example, if you setup your clocks in the bootloader before deciding to jump to the application, you may run into problems in your application if it assumes that the clocks are in the default configuration already. Similar things can happen with the NVIC and SysTick if your bootloader is using these before jumping to the application.

Lastly, along the same lines as the previous section, the application may be making assumptions about the state of peripherals being default, but it also may be making assumptions that the peripheral defaults are correct. For example: SCB->VTOR has a default value (I believe it is always 0x00000000), and this points to the vector table. Your bootloader will be linked to have its vector table at that location. You'll need to make sure that when your application is starting up, it updates the VTOR register to point to the actual location of its vector table.

Hopefully one of these sections helps you identify the problem.

rjp
  • 1,760
  • 13
  • 15
  • Thanks at all. **(1)** My boot loader has configured system clock. Because it's the first job to do in the startup.s. And the startup.s in application also reinitialize it. **(2)** And as in my post, the RTX os kernel is running, but it is in a endless loop switch tasks. All tasks were in "READY" states, but the OS kernel could not put one of them in the "RUNNING" state. So there were no chances for the main and user threads to be called. – lrouter Sep 04 '16 at 13:21