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. > >>> > >> > >
