Just a follow up for the list- It turns out there were a number of issues with split images. I believe they have all been resolved now. Some of the required changes were non-trivial, so I wanted to summarize what I did.
1. bleprph doesn't jump to app (slot 2). This one is straightforward. The bleprph app wasn't written to behave as a loader. Rather, it always started the OS, even when configured to run the second stage app. The fix was just to copy and paste the generic loader code from slinky. 2. Jump from loader to app required too much RAM. When a loader transitions to the second stage app, it executes a modified version of the boot loader. The boot loader was using quite a bit of RAM for caching information about the layout of sectors within the image slots. In normal, non-split, operation, such RAM usage isn't a problem because there is no OS running, and therefore no other code to share memory with. In the modified version that runs during the split transition, other code *is* running, so RAM for the sector cache gets allocated via malloc(). About 4kB was getting malloced here, which was failing for me when running on the 16 kB RAM nRF51dk BSP. The fix is to not cache the sector data, but to read it when needed. 3. Loader-only packages were not getting initialized in the second stage app. This was a bug in the newt tool. When generating the sysinit_app() function, the tool excluded packages which are not explicitly referenced in the app's dependency tree. This is wrong; all packages should get initialized in the second stage app. Thanks, Chris On Fri, Jan 13, 2017 at 04:38:25PM -0700, Jacob Rosenthal wrote: > Ah, I expected gdb of optimized split code to be a nightmare and hadnt > tried yet. > newtmgr has never crashed.. it just hangs forever > > I cant get the SOFT anymore now..... hrmmm Just hanging out here.. > (gdb) where > #0 os_tick_idle (ticks=1189) at > repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/src/hal_os_tick.c:158 > #1 0x00008c1e in os_idle_task (arg=<optimized out>) at > repos/apache-mynewt-core/kernel/os/src/os.c:110 > #2 0x00000000 in ?? () > (gdb) c > > Any chance I could impose on you to debug in irc with me sometime? > > > On Thu, Jan 12, 2017 at 9:42 PM, Christopher Collins <ccoll...@apache.org> > wrote: > > > Hi Jacob, > > > > If that reboot log entry is recent, it looks like your device is > > crashing. A reason of "SOFT" indicates a firmware crash [*]. I would > > say the quickest way to debug this is to run the code in gdb. You can > > do this with the "newt run" command: > > > > newt run <target-name> 0 > > > > When gdb comes up, type c and press enter. Then in a different shell, > > send a newtmgr command to the device. If device crashes, gdb should > > indicate such. If Mynewt crashes, can you please type the following > > commands in gdb: > > > > bt > > p *g_current_task > > p os_msys_init_1_mempool > > > > And send the output? > > > > Thanks, > > Chris > > > > [*] Augmenting the reboot log entry with the line number and filename > > where the crash occurred is on the to do list. > > > > > > On Thu, Jan 12, 2017 at 08:41:03PM -0700, Jacob Rosenthal wrote: > > > > > > > > > turned off a ton more bluetooth shit for more ram > > > > > > both still hang: > > > newtmgr -c serial1 logs log_list > > > newtmgr -c serial1 image list > > > > > > but log in shell now has: > > > newtmgr 4976:Dumping log reboot_log > > > > > > > > > On Thu, Jan 12, 2017 at 8:33 PM, Jacob Rosenthal < > > jakerosent...@gmail.com> > > > wrote: > > > > > > > log on shell shows lots of these > > > > > > > > 9050:[0] rsn:SOFT, cnt:1, img:0.0.0.0 > > > > > > > > On Thu, Jan 12, 2017 at 8:28 PM, Jacob Rosenthal < > > jakerosent...@gmail.com> > > > > wrote: > > > > > > > >> All newtmgr commands on serial are hanging indefinitely. > > > >> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr -c > > serial1 > > > >> image list > > > >> ^C > > > >> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr conn > > show > > > >> Connection profiles: > > > >> serial1: type=serial, connstring='/dev/tty.usbmodem1411' > > > >> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ > > > >> > > > >> Looks like it works for the splitty/slinky demo > > > >> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr -c > > serial1 > > > >> image list > > > >> Images: > > > >> slot=0 > > > >> version: 0.0.0 > > > >> bootable: true > > > >> flags: active confirmed > > > >> hash: 21439de02cbf31626856374f44cbd4 > > 90fd6def3ce3062b63d55ed2c19a8b > > > >> 2b83 > > > >> slot=1 > > > >> version: 0.0.0 > > > >> bootable: false > > > >> flags: > > > >> hash: 8b64ea89bf0495c0ccb25b96b3a7f0 > > 6fd5e540e221f9659f9bc6b0d0d303 > > > >> d6f1 > > > >> Split status: matching > > > >> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ > > > >> > > > >> Ram issue? Whats a good way to see a log of the failed attempt since I > > > >> have the shell? > > > >> > > > >> > > > >> > > > >> On Thu, Jan 12, 2017 at 7:51 PM, Christopher Collins < > > ccoll...@apache.org > > > >> > wrote: > > > >> > > > >>> On Thu, Jan 12, 2017 at 07:06:37PM -0700, Jacob Rosenthal wrote: > > > >>> > Still ok... and Im able to interact with shell over serial and I > > > >>> think its > > > >>> > advertising!? Not sure why my newtmgr wont connect then.. Ideas to > > > >>> > troubleshoot? > > > >>> > > > >>> So you are sending newtmgr commands over serial? Do all commands > > fail, > > > >>> or just image list? > > > >>> > > > >>> > Also I was digging and found someone already PRed a ble transport > > for > > > >>> > newtmgr https://github.com/apache/incubator-mynewt-core/pull/73/ > > files > > > >>> > but the api is a bit different now.. Anyone using that? > > > >>> > > > >>> Yes, the newtmgr BLE characteristic is being used and should work. > > The > > > >>> newtmgr command line tool has rudimentary support for BLE, but only > > when > > > >>> run on linux. > > > >>> > > > >>> Thanks, > > > >>> Chris > > > >>> > > > >> > > > >> > > > > > >
