Hi Louie, thanks for the pointer to code. I can see that the startup code is probably what you should look at.
Contrast and compare those against the file stm32f4discovery uses. Here are few things I noticed: interrupt vector holds ‘__StackTop’ as the pointer to initial stack. I notice in common file you’re setting ‘_estack’, and then set it inside the assembly. This should not be needed; for bootloader the MCU reset loads the first 4 bytes to SP at startup, and when app is booting up, bootloader does the same thing. Most likely the reason you’re not able to boot this properly is the entry point called at the end of startup; it should call _start, not main. This is needed because _start() sets up the OS, and we use main() as the entry point to ‘default task’. Hope this helps. Let me know if you want me to take another look, M > On Mar 6, 2017, at 6:40 PM, Louie Lu <[email protected]> wrote: > > Hi Marko, > > Yep, you are right, I got some bad setting in linker script with _estack > value. > > I'm now using the branch here: > https://github.com/grapherd/incubator-mynewt-core > which derived from master: 8cf8f54dcf4cb2d > > I've trying to give the space for _estack, it CCM or at the end of the RAM, > > (it used in startup_stm32f429xx.s for sp value) > Reset_Handler: > ldr sp, =_estack /* set stack pointer */ > > > But the result came a little different, > First, is sometimes still got unhandled interrupt 3, > and second, function parameter didn't got right. > e.g. os_time_delay(osticks) will get a junk value even the value is > hardcode in main.c, > > Using debugger, I can see that the junk value is in the stack zone, > but no correct value I pass into it. > > > Thanks, > Louie. > > 2017-03-07 1:42 GMT+08:00 marko kiiskila <[email protected]>: > >> Interrupt 3 means Hard fault. Cursory read of the register dump >> included seems to indicate ‘unaligned access’. And the fault >> happens within context switching code. >> >> Which git branch are you using? Or git tag. I might be able to give >> more hints if I knew which version of HAL_CM4.S, line 163 you have. >> My guess is that it is the saved stack pointer within some task >> structure which is causing the fault. Check for stack overflows. >> >>> On Mar 5, 2017, at 7:38 PM, Louie Lu <[email protected]> wrote: >>> >>> Hi Sterling, >>> >>> Thanks for your reply, this is the info I got from debugger and serials: >>> >>> serials core dump: >>> >>> 0:Unhandled interrupt (3), exception sp 0x2002ff90 >>> 0: r0:0x00000000 r1:0x20001144 r2:0x00000000 r3:0x200012b0 >>> 0: r4:0x00000000 r5:0x00000000 r6:0x20001144 r7:0x08023684 >>> 0: r8:0x00000000 r9:0x08020935 r10:0x00000000 r11:0x00000000 >>> 0:r12:0x2002ffff lr:0xfffffff9 pc:0x0802134c psr:0x2100000e >>> 0:ICSR:0x00436003 HFSR:0x40000000 CFSR:0x01000000 >>> 0:BFAR:0xe000ed38 MMFAR:0xe000ed34 >>> >>> >>> gdb debugger backtrace: >>> >>> (gdb) bt >>> #0 0x08021f14 in hal_uart_blocking_tx (port=<optimized out>, data=48 >> '0') >>> at hal_uart.c:171 >>> #1 0x08021b36 in uart_hal_blocking_tx (dev=<optimized out>, >>> byte=<optimized out>) >>> at uart_hal.c:64 >>> #2 0x200012c8 in console_is_midline () >>> Backtrace stopped: previous frame identical to this frame (corrupt >> stack?) >>> (gdb) bt >>> #0 hal_system_reset () at hal_system.c:33 >>> #1 0x08020810 in os_default_irq (tf=0x2002ff68) at os_fault.c:159 >>> #2 0x0802137a in os_default_irq_asm () at HAL_CM4.S:207 >>> #3 <signal handler called> >>> #4 PendSV_Handler () at HAL_CM4.S:163 >>> #5 <signal handler called> >>> #6 0x0802101c in os_sched (next_t=next_t@entry=0x0) at os_sched.c:150 >>> #7 0x08020932 in os_time_delay (osticks=osticks@entry=536875332) at >>> os_time.c:132 >>> #8 0x0802024a in main (argc=<optimized out>, argv=<optimized out>) at >>> main.c:73 >>> >>> ---- >>> >>> (gdb) bt >>> #0 hal_system_reset () at hal_system.c:33 >>> #1 0x08020810 in os_default_irq (tf=0x2002ff68) at os_fault.c:159 >>> #2 0x0802137a in os_default_irq_asm () at HAL_CM4.S:207 >>> #3 <signal handler called> >>> #4 PendSV_Handler () at HAL_CM4.S:163 >>> #5 <signal handler called> >>> #6 0x0802101c in os_sched (next_t=next_t@entry=0x0) at os_sched.c:150 >>> #7 0x08020932 in os_time_delay (osticks=osticks@entry=536875332) at >>> os_time.c:132 >>> #8 0x0802024a in main (argc=<optimized out>, argv=<optimized out>) at >>> main.c:73 >>> >>> >>> >>> >>> Not sure how to handle the interrupt, is the interrupt three mean the >> NVIC >>> 3 interrupt? >>> >>> >>> Thanks, >>> Louie. >>> >>> 2017-03-06 10:55 GMT+08:00 Sterling Hughes < >> [email protected] >>>> : >>> >>>> Hi Louie, >>>> >>>> Excellent! We’d love the port when you’re done. >>>> >>>> That usually means a crash of some type has occurred? Can you attach a >>>> debugger, you should be able to see a stack trace (similarly - if you >> can >>>> get the console attached, it should *fingers-crossed* dump to console.) >>>> >>>> Alternatively, mynewt can generate crash dumps which you can trigger and >>>> pull back, it’s been awhile since I looked at this, but hopefully >> somebody >>>> else on the list can give you instructions on generating cores on the >>>> STM32F* series. >>>> >>>> Sterling >>>> >>>> >>>> On 5 Mar 2017, at 18:38, Louie Lu wrote: >>>> >>>> Hi everyone, >>>>> >>>>> I'm now porting mynewt to STM32F429, and this board has the same MCU >> and >>>>> CPU with the board STM32F07 which mynewt have already supported. >>>>> >>>>> I have now using blinky and slinky to verify the correctness of >> porting, >>>>> but encounter the problem that serial output "Unhandled interrupt (3)" >>>>> often, when MyNewt calling "os_time_delay" the second time, and >> sometime >>>>> in >>>>> "log_reboot_pkg_init". >>>>> >>>>> I'm not sure where do I doing wrong, do anyone has some clue or suggest >>>>> that I can do now? >>>>> >>>>> Thanks, >>>>> Louie. >>>>> >>>> >> >>
