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. This is the debugging picture.
I could not find the reason, so I come here for help. Thanks.
Do you need that system clock? The processor must already have a working oscillator to reach that function. Does it break any assumption of the actual application that thinks it is responsible for setting up the clock?
Because the problem is that you are somehow breaking an assumption of the application.
Do you understand the concept of a processor running in a USER state, and a SYSTEM state, and what that implies about the things you can do, and what might be prohibited?
Then also consider if the processor is in an INTERRUPT context, and that you can't clear that jumping to some other random code. ie don't transfer control from an interrupt, button press, systick, etc.
In the beginning of application image, there is also a startup.s file which will re-initialize system clock frequency. So I don't think initializing system clock frequency will not break the assumption.
That depends on the order of instructions.
If the second initialization performs the steps one by one and gets surprised by the boot loader having already run through the full list.
Things that might normally take time - like synchronizing a PLL - can suddenly be already done. Depending on how the code is written, this can lead to unexpected results, similar to when code tries to initialize a UART, and the UART has already been initialized and already have received data that is just waiting for the interrupt flag to be enabled.
The interesting with "So I don't think initializing system clock frequency will not break the assumption." is that you are making an assumption that two calls will not breaking any assumptions. Lots of assumptions involved, and assumptions are bad. Better make sure.