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