Hi Aditi, Should porting patch as will as using GitHub PR?
Thanks, Louie. 2017-03-09 18:32 GMT+08:00 aditi hilbert <[email protected]>: > Hi Louie, > > Thank you for fixing a bug! The best way is to submit a PR on github. For > now you can issue the PR against the develop branch. Eventually we will > only have feature or subsystem branches, so the PRs will be submitted > against the applicable branch or master. Right now we have the develop > branch to submit the PR against. > > thanks, > aditi > > > > On Mar 9, 2017, at 11:09 AM, Louie Lu <[email protected]> wrote: > > > > 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 <[email protected]>: > > > >> 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. > >>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
