STemWin -> GUI_Init() hangs after use of a 2nd Level Bootloader on STM32F429

[mforcemeichle]

Posted on January 17, 2015 at 21:24

Dear Forum Members,

I'm struggeling for quite a while now with this Problem:

I run STemWin, the precompiled emWin version lincensed for ST, on a ST32F429. Everything worked fine until I made use of OpenBLT, a second level bootloader.

If I try to flash my user application from SDCard that contains STemWin, the user application hangs at GUI_Init();

I expect it to have something to do with the memory allocation. So I'm asking if its in general not possible to run the precompiled STemWin from a flash location other than 0x08000000 ? Because I moved the user application 48K to 0x0800C000 because the bootloader occupies the space in front.

I suspect the Linker script to be faulty maybe also.

Also asked the same question in the Segger forums, no help so far. It maybe ain't a emWin issue therefore:

http://forum.segger.com/index.php?page=Thread&threadID=1889

(someone having almost the same problem - > unfortunately he didn't say what it was.)

I'm hoping that someone here can help me, I still couldnt solve the issue for quite a while now and it starts to get annoying ;)

Tell me if you need more info.

Thanks in advance!

[Tesla DeLorean]

Posted on January 17, 2015 at 22:23

Precompiled libraries don't care where you link them. If you change the base of a compiled application you'll need to address that in SystemInit() where it sets the vector table base address in SCB->VTOR

If you use an RTOS, or a boot loader that uses interrupts, you'll need to pay attention to how that gets handed off to the application.

Use a debugger, and understand where it hangs. Use a proper Hard Fault Handler so you can identify failures.

[mforcemeichle]

Posted on January 18, 2015 at 14:53

Thanks so far Clive,

I tried to debug the user application, and it seems that there is some interrupt firing constantly right after the _RemoveHoles section in the GUI_Init stuff: It runs to the yellow marked line and jumps from there to the red marked one. After the red one the Interrupt start firing continously and the disassembly view of my CooCox IDE rests at ''00000000: movs r0, r0''.

_RemoveHoles:
0801fec4: ldr r3, [pc, #136] ; (0x801ff50 <
_RemoveHoles
+140>)
0801fec6: stmdb sp!, {r0, r1, r2, r4, r5, r6, r7, r8, r9, r10, r11, lr}
0801feca: mov r11, r0
0801fecc: ldr r0, [r3, #8]
0801fece: ldr r4, [r3, #52] ; 0x34
0801fed0: add.w r10, r0, #4294967295
0801fed4: add r10, r4
0801fed6: ldmia.w r4, {r3, r5}
0801feda: cmp r3, #0
0801fedc: bne.n 0x801ff40 <
_RemoveHoles
+124>
0801fede: add.w r8, r4, r5
0801fee2: cmp r8, r10
0801fee4: bcs.n 0x801ff40 <
_RemoveHoles
+124>
0801fee6: ldr.w r9, [r4, r5]
0801feea: ldr.w r7, [r8, #4]
0801feee: cmp.w r9, #0
0801fef2: beq.n 0x801ff40 <
_RemoveHoles
+124>
0801fef4: ldr r6, [pc, #88] ; (0x801ff50 <
_RemoveHoles
+140>)
0801fef6: ldr r1, [r6, #48] ; 0x30
0801fef8: ldrb.w r2, [r1, r9, lsl #3]
0801fefc: cmp r2, #1
0801fefe: bne.n 0x801ff40 <
_RemoveHoles
+124>
0801ff00: ldr r3, [r6, #40] ; 0x28
0801ff02: mov r0, r4
0801ff04: str r3, [sp, #4]
0801ff06: bl 0x801fdfc <
_RemoveFreeBlock
>
0801ff0a: ldr.w r0, [r8]
0801ff0e: ldr r1, [r6, #48] ; 0x30
0801ff10: add.w r2, r1, r0, lsl #3
0801ff14: mov r0, r4
0801ff16: str r4, [r2, #4]
0801ff18: mov r1, r8
0801ff1a: mov r2, r7
0801ff1c: bl 0x8023f78 <
memmove
>
0801ff20: ldr r3, [sp, #4]
0801ff22: cmp r9, r3
0801ff24: bne.n 0x801ff2c <
_RemoveHoles
+104>
0801ff26: ldr r0, [r6, #48] ; 0x30
0801ff28: subs r1, r0, r5
0801ff2a: str r1, [r6, #48] ; 0x30
0801ff2c: mov r0, r5
0801ff2e: adds r1, r4, r7
0801ff30: bl 0x801fe38 <
_AddFreeMemory
>
0801ff34: cmp.w r11, #0
0801ff38: beq.n 0x801ff3e <
_RemoveHoles
+122>
0801ff3a: cmp r11, r0
0801ff3c: bls.n 0x801ff4a <
_RemoveHoles
+134>
0801ff3e: mov r5, r7
0801ff40: adds r4, r4, r5
0801ff42: cmp r4, r10
0801ff44: bcc.n 0x801fed6 <
_RemoveHoles
+18>
0801ff46: movs r0, #1
0801ff48: b.n 0x801ff4c <
_RemoveHoles
+136>
0801ff4a: movs r0, #0
0801ff4c: ldmia.w sp!, {r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, pc}
0801ff50: bic.w r0, r8, #532480 ; 0x82000

It says its some command about loading multiple registers. Does it say something to you? I'm pretty confused by now because I don't understand why now there is a interrupt firing from there on. Or is this the hardfault handler?

[Tesla DeLorean]

Posted on January 18, 2015 at 15:07

It tells me to look at the value in R4

Ok, understand what the loader code you added does. Does it enable interrupts (SysTick, SDIO, DMA, etc), and are those all disabled or closed out before you take control and move the vector table. Put a break point in the default handler code.

[mforcemeichle]

Posted on January 18, 2015 at 19:41

It appears that the Interrupt called immediatly after the GUI_Init call is the HardFault_Handler.

I still dont get how to deal with that though.

All the other interrupts used in the Bootloader itself were turned of properly before.