Hi Louie, Just the github PR is good.
The link in your previous email is for giving a developer a committer status (i.e someone who can directly commit changes to the Apache repo without having to go through github PRs) thanks, aditi > On Mar 9, 2017, at 11:45 AM, Louie Lu <[email protected]> wrote: > > 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. >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
