[En-Nut-Discussion] STM32: Problems running code with an offset in flash (bootloader)

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> 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 at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------