Re: STM32: Problems running code with an offset in flash (bootloader)
Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Thu, 3 Mar 2016 10:23:22 +0100
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Ole" == Ole Reinhardt <ole.reinhardt-L1vi/[email protected]> writes: Ole> Hi all, has anyone just compiled a program for STM32 that is not Ole> linked to the beginning of the flash? Ole> I need to link my program to a start address of 0x0800c000, as my Ole> system runs a bootloader, that expects its application code at this Ole> address. Ole> CPU: STM32F411CE Ole> To do so, I added a local linker script that defienes a Ole> bootloader_offset of 0xC000 and includes stm32f10x_flash.ld: Ole> ---------------------------- ENTRY(NutInit) SEARCH_DIR(.) Ole> "bootloader_offset" = 0xC000; Ole> MEMORY { FLASH0 (rx) : ORIGIN = 0x08000000, LENGTH = 512K SRAM0 Ole> (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } Ole> INCLUDE stm32f10x_flash.ld ---------------------------- Ole> Further I added Ole> .bootloader (NOLOAD): { . = bootloader_offset; } > FLASH0 Ole> Right at the top of stm32f10x_flash.ld (similar to Ole> stm32f10x_ram.ld) Ole> The application is started correctly and I can output some debug Ole> messages using the DebugPut() routine (Debug Macro). I also can Ole> register the UART driver and output a few bytes using printf(). Ole> So far everything looks fine, but as soon as the programs gets a Ole> little more complex it hangs / crashes. Unfortunately I don't have Ole> a JTAG connected, so I can not evaluate any register contents. Ole> Neither a call to NutSleep() nor to NutGetMillis() returns, but on Ole> the other hand NutThreadYield works without any problems. Ole> For example I can create two threads both printing characters with Ole> DebugPut and then calling NutThreadYield. That works as expected, Ole> but as soon as I call NutSleep() the program hangs / crashes. Ole> I also can not print longer strings using printf(). Again the Ole> program gets stuck, while when adding a few DebugPut() calls Ole> between several printf() calls, the output is printed as expected. Ole> I have the strong feeling, that the interrupt handling won't work Ole> anymore when not linking to the flash base address (0x08000000). Ole> a) the timer interrupt is needed for NutSleep() b) the UART driver Ole> prints out data using an interrupt. When calling DebugPut() in Ole> between, this routine does not wait for an interrupt, but polls the Ole> UART status register to wait for the FIFO to get empty again. Ole> b also explains, why printing short text using printf() works, but Ole> longer text outputs get stuck. A longer text needs interrupt Ole> interaction while a shorter text fits into the UART FIFO. Ole> Does anyone of you have an idea what could cause such a behaviour? Ole> How could the behaviour be related to either the offset where the Ole> code is linked to or to any settings that the bootloader Ole> configures? Ole> I'm wondering if the bootloader could have disabled all interrupts Ole> and the STM32 startup code does not re-enable them? Ole> I'm a little out of good ideas... cmsis/cortex_init.c line 431 is in charge to remap the interrupt vectors. I guess something goes wrong there. Without a debugger, things are hard to debug. But the ESP board has listed "SWD debug interface". And I know you have some ST boards with Stlink at least version 2. So you could try to set up a SWD connection from the SWD extension connector on the Stlink board to your ESP board with flying wires. Otherwise check in your map file that interrupt vector remap is set up sensible. You could also recreate your bootloader setup on your STM board. Here SWD connection is on the board direct, so no need for flying wires. Or perhaps post or send me your a test example and I can test and debug on some of my bords, as time allows. Hope this helps -- Uwe Bonnes bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion