Hi Marko, Thanks for your help, your tips are very useful, after some retry and your tips, I finally let blinky work properly on STM32F429. I'm now getting forward to slinky and try to make it OK.
Another question is, I found a bug that isn't directly related with porting stuff, if I want to send a patch, how can I do? On the documentation, it seem there have to two ways to submit the patch (GitHub and PPMC* (?)). Which should I take? Thanks, Louie. * https://cwiki.apache.org/confluence/display/MYNEWT/New+Committer+Acceptance+Process#NewCommitterAcceptanceProcess-Step6:Newcommitteraccountsetup 2017-03-08 1:29 GMT+08:00 marko kiiskila <ma...@runtime.io>: > 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 <m...@louie.lu> 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 <ma...@runtime.io>: > > > >> 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 <m...@louie.lu> 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 < > >> sterling.hughes.pub...@gmail.com > >>>> : > >>> > >>>> 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. > >>>>> > >>>> > >> > >> > >
