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