You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Jacob Rosenthal <ja...@gmail.com> on 2017/01/02 06:10:01 UTC
Single Bank firmware update (ie nordic vendor style dfu)
On low flash devices like nrf51822 FLASH_AREA_IMAGE_1 equal to
FLASH_AREA_IMAGE_0 is improbable, which means dual bank is likewise
improbable and as a result we've talked previously about how to shrink
FLASH_AREA_IMAGE_1 down to a stub.
However, my current understanding is newtmgr/imagemgr implementation is
dual bank, wherein the application saves received bytes into
COREDUMP_FLASH_AREA (ie FLASH_AREA_IMAGE_1) and reboots allowing bootloader
(apps/boot) to safely make the swap.
I don't believe theres a good way to do a single bank receive from within
the running application, which would mean this has to be moved into the
bootloader, which means it need to share access to nimble, which means a
bootloader fork that includes splitty, nimble, newtmgr, imagemgr.
Im somewhat unclear if the 'loader' app can/should also serve as the
'bootloader', or if it was intended that a separate bootloader would also
be present in addition to loader and application?
Thoughts on this architecture, am I missing anything?
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
On Thu, Jan 12, 2017 at 07:19:11PM -0700, Jacob Rosenthal wrote:
> OH really interesting.. In the updated documentation the biggest change
> from what I was doing was splitty is the app and bleprph is the loader. Is
> that intentional?
Yes - the loader needs to contain everything required for an image
upgrade. The bleprph app contains the BLE stack and the newtmgr /
imgmgr server. These components are what is required for an
over-the-air upgrade, so it makes sense to use bleprph as the loader.
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
OH really interesting.. In the updated documentation the biggest change
from what I was doing was splitty is the app and bleprph is the loader. Is
that intentional?
On Thu, Jan 12, 2017 at 7:06 PM, Jacob Rosenthal <ja...@gmail.com>
wrote:
> OK.. Thanks so much for keeping on this with me.
>
> Im on nrf51dk-16kbram, so I swapped to that. Based on your numbers Id
> still be running out of ram for the so I shrunk MSYS_1_BLOCK_SIZE as has
> been discussed:
> MSYS_1_BLOCK_SIZE: 76
>
> text data bss dec hex filename
> 4936 112 15024 20072 4e68 /Users/jacobrosenthal/
> Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/
> apps/splitty/splitty.elf
> Size of Loader Image: loader
> 110364 1172 10920 122456 1de58 /Users/jacobrosenthal/
> Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/
> loader/apps/bleprph/bleprph.elf
>
> Looks better, but newtmgr image list seems to be hanging or timing out...
> so I enable the shell
> STATS_NEWTMGR: 0
> CONFIG_NEWTMGR: 0
> SHELL_TASK: 1
> LOG_CLI: 1
>
> text data bss dec hex filename
> 1424 0 15104 16528 4090 /Users/jacobrosenthal/
> Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/
> apps/splitty/splitty.elf
> Size of Loader Image: loader
> 112356 1268 11048 124672 1e700 /Users/jacobrosenthal/
> Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/
> loader/apps/bleprph/bleprph.elf
>
> 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?
>
> 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?
>
> Thanks again. As Im sure you know, Hardly anyone else has a ble stack, and
> nobody else's configures for 16kb targets, so this is pretty amazing.
>
>
> On Thu, Jan 12, 2017 at 10:03 AM, Christopher Collins <ccollins@apache.org
> > wrote:
>
>> On Mon, Jan 09, 2017 at 10:48:48AM -0800, Christopher Collins wrote:
>> > The boot sequence and upgrade procedure for the split image setup is a
>> > bit complicated. I have been working on some documentation for this
>> > area, but haven't quite finished it. I hope to have something ready in
>> > a day or two. In the meantime, please feel free to ask any follow up
>> > questions.
>>
>> FYI - The split image documentation has been updated on the Mynewt site:
>> http://mynewt.apache.org/latest/os/modules/split/split/
>>
>> Chris
>>
>
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
On Tue, Jan 17, 2017 at 09:06:36PM -0700, Jacob Rosenthal wrote:
[...]
> As you can see, I cant seem to get slot1 active and confirmed
It looks like one of two things is going wrong:
1. The loader (bleprph) is failing to jump into the application
(splitty), or
2. The application (splitty) is crashing immediately.
Do you have the latest newt tool from develop? There was a bug in the
newt tool which would cause issue 2, but it was fixed a few days ago.
If I recall the bug, splitty's sysinit was initializing the the host
package, but not the HCI transport package, causing an invalid memory
access when host started up.
Anyway, if you don't have the latest newt, try pulling from develop and
reinstalling. Otherwise, I think the next step is to debug this in gdb.
Feel free to reach out here or on IRC.
Thanks,
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
Used your settings to be sure were the same (cool override in the target)
JLinkExe -if SWD -device nRF51822 -speed 1000
erase all
q
newt size shows were under 112238
110532 1276 10664 122472 1de68
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/loader/apps/bleprph/bleprph.elf
newt build nordic_boot && newt load nordic_boot
newt run split-nrf51dk 0
just quit after loading since we gdb cant survive reset anyway
plug and unplug usb so it starts code
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image list -c
serial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 0fb87218d68acf905c646473b1c8361aa3d6236187368ec9862ed8d021e89197
slot=1
version: 0.0.0
bootable: false
flags:
hash: 6645241f6e639d9a3d30ca31691736c7d981397c16947247c56f75b76ec140ba
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image test
6645241f6e639d9a3d30ca31691736c7d981397c16947247c56f75b76ec140ba -cserial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 0fb87218d68acf905c646473b1c8361aa3d6236187368ec9862ed8d021e89197
slot=1
version: 0.0.0
bootable: false
flags: pending
hash: 6645241f6e639d9a3d30ca31691736c7d981397c16947247c56f75b76ec140ba
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset
-cserial1
Done
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image confirm
-cserial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 0fb87218d68acf905c646473b1c8361aa3d6236187368ec9862ed8d021e89197
slot=1
version: 0.0.0
bootable: false
flags:
hash: 6645241f6e639d9a3d30ca31691736c7d981397c16947247c56f75b76ec140ba
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$
As you can see, I cant seem to get slot1 active and confirmed
On Tue, Jan 17, 2017 at 6:43 PM, Christopher Collins <cc...@apache.org>
wrote:
> On Tue, Jan 17, 2017 at 05:47:49PM -0700, Jacob Rosenthal wrote:
> > Thanks Chris! Tried some more with the new upstreamed code but a few
> > more issues...
> >
> >
> > Still had to add the serial transport to bleprph, not sure if you left
> > that out of there on purpose for code size.. -
> > mgmt/newtmgr/transport/nmgr_shell
>
> Yes, you guessed right. I was reluctant to add serial newtmgr support
> to bleprph because I think most people would appreciate the extra flash.
>
> > newt run split-nrf51dk 0
> >
> >
> > and it responds to newtmgr serial commands now.. But never blinks..
>
> bleprph doesn't blink the LED. We should change this :).
>
> > Looks like its hitting os_start in the loader because rc =
> > split_app_go(&entry, true); returns -1
> >
> > because (gdb) p split_mode_cur $6 = 0 '\000'
> >
> > which is SPLIT_MODE_LOADER I think it should be SPLIT_MODE_APP??
> > maybe?
>
> SPLIT_MODE_LOADER is the default state. You need to activate the
> application image using newtmgr if you want it to run (see the "Enabling
> a Split Application" section of
> https://mynewt.apache.org/latest/os/modules/split/split/).
>
> > Also I just decided to go through with newtmgr upload commands, but they
> > crash:
>
> Hmm, I wasn't able to reproduce that. I am attaching my target's yml
> files so we can compare.
>
> There is one possibility I can think of: Your images might be too big.
> I am using a LOG_LEVEL setting of 255, while I believe you are using 1.
> This will make your images quite a bit larger. There are a few things
> you need to watch out for with large images:
>
> 1. When building a split image loader, the newt tool doesn't apply the
> correct flash size restrictions from the BSP linker script, so your
> loader can end up being too large. What should happen instead is the
> link step should fail due to flash overflow. This is a nasty bug;
> hopefully we'll have it fixed soon
> (https://issues.apache.org/jira/browse/MYNEWT-545).
>
> 2. If an image barely fits in the image slot, this will cause problems
> for the boot loader and image management. The end of each slot is used
> for keeping track of the current image management state. If the end of
> an image is written here, it will be wrongly interpreted as image state,
> likely causing a crash. I think once we get the format of the image
> trailers formalized, we should be able to prevent this issue from
> happening.
>
> For now, be aware that each image slot needs room for a 402 byte
> trailer. This means that on the 256kB flash nRF51dk, the absolute
> largest an image can be is: 112238 bytes. If your loader is bigger than
> this, then you'll run into problems.
>
> Finally, if either of these issues occurred, then you'll need to erase
> the overfilled image slot before proceding. Otherwise, the garbage data
> will remain and continue to confuse the boot loader. You may already
> know a good way to do this... I erase the entire flash as follows:
>
> JLinkExe -device nRF51 -speed 4000 -if SWD
> erase
>
> Then quit JLinkExe. You'll need to re-upload the boot loader after
> doing this. Sorry, I know this is a major hassle.
>
> Chris
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
On Tue, Jan 17, 2017 at 05:47:49PM -0700, Jacob Rosenthal wrote:
> Thanks Chris! Tried some more with the new upstreamed code but a few
> more issues...
>
>
> Still had to add the serial transport to bleprph, not sure if you left
> that out of there on purpose for code size.. -
> mgmt/newtmgr/transport/nmgr_shell
Yes, you guessed right. I was reluctant to add serial newtmgr support
to bleprph because I think most people would appreciate the extra flash.
> newt run split-nrf51dk 0
>
>
> and it responds to newtmgr serial commands now.. But never blinks..
bleprph doesn't blink the LED. We should change this :).
> Looks like its hitting os_start in the loader because rc =
> split_app_go(&entry, true); returns -1
>
> because (gdb) p split_mode_cur $6 = 0 '\000'
>
> which is SPLIT_MODE_LOADER I think it should be SPLIT_MODE_APP??
> maybe?
SPLIT_MODE_LOADER is the default state. You need to activate the
application image using newtmgr if you want it to run (see the "Enabling
a Split Application" section of
https://mynewt.apache.org/latest/os/modules/split/split/).
> Also I just decided to go through with newtmgr upload commands, but they
> crash:
Hmm, I wasn't able to reproduce that. I am attaching my target's yml
files so we can compare.
There is one possibility I can think of: Your images might be too big.
I am using a LOG_LEVEL setting of 255, while I believe you are using 1.
This will make your images quite a bit larger. There are a few things
you need to watch out for with large images:
1. When building a split image loader, the newt tool doesn't apply the
correct flash size restrictions from the BSP linker script, so your
loader can end up being too large. What should happen instead is the
link step should fail due to flash overflow. This is a nasty bug;
hopefully we'll have it fixed soon
(https://issues.apache.org/jira/browse/MYNEWT-545).
2. If an image barely fits in the image slot, this will cause problems
for the boot loader and image management. The end of each slot is used
for keeping track of the current image management state. If the end of
an image is written here, it will be wrongly interpreted as image state,
likely causing a crash. I think once we get the format of the image
trailers formalized, we should be able to prevent this issue from
happening.
For now, be aware that each image slot needs room for a 402 byte
trailer. This means that on the 256kB flash nRF51dk, the absolute
largest an image can be is: 112238 bytes. If your loader is bigger than
this, then you'll run into problems.
Finally, if either of these issues occurred, then you'll need to erase
the overfilled image slot before proceding. Otherwise, the garbage data
will remain and continue to confuse the boot loader. You may already
know a good way to do this... I erase the entire flash as follows:
JLinkExe -device nRF51 -speed 4000 -if SWD
erase
Then quit JLinkExe. You'll need to re-upload the boot loader after
doing this. Sorry, I know this is a major hassle.
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
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
It would be interesting to see how many mbufs are free:
p os_msys_init_1_mempool
> Any chance I could impose on you to debug in irc with me sometime?
Sure. I'm on IRC, so just shout any time.
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
Thanks Chris!
Tried some more with the new upstreamed code but a few more issues...
Still had to add the serial transport to bleprph, not sure if you left that
out of there on purpose for code size..
- mgmt/newtmgr/transport/nmgr_shell
newt run split-nrf51dk 0
and it responds to newtmgr serial commands now..
But never blinks..
Looks like its hitting os_start in the loader because
rc = split_app_go(&entry, true); returns -1
because
(gdb) p split_mode_cur
$6 = 0 '\000'
which is SPLIT_MODE_LOADER
I think it should be SPLIT_MODE_APP?? maybe?
Also I just decided to go through with newtmgr upload commands, but they
crash:
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image list -c
serial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: ff846c585a34185c24f46166547a6447f1c82de94fe2ab93033dc40903d873b1
slot=1
version: 0.0.0
bootable: false
flags:
hash: 75379446f1c26f11b86f521f06636c0fcd4c28f3b14e192fe3331ba4504330ff
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image test
75379446f1c26f11b86f521f06636c0fcd4c28f3b14e192fe3331ba4504330ff -c serial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: ff846c585a34185c24f46166547a6447f1c82de94fe2ab93033dc40903d873b1
slot=1
version: 0.0.0
bootable: false
flags: pending
hash: 75379446f1c26f11b86f521f06636c0fcd4c28f3b14e192fe3331ba4504330ff
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset
-cserial1
Done
Crashes....
(gdb) p *g_current_task
$1 = {t_stackptr = 0x20004000, t_stacktop = 0xc1, t_stacksize = 313,
t_taskid = 0 '\000', t_prio = 0 '\000', t_state = 57 '9', t_flags = 1
'\001',
t_lockcnt = 0 '\000', t_pad = 0 '\000', t_name = 0x0, t_func = 0x0, t_arg
= 0x0, t_obj = 0x0, t_sanity_check = {sc_checkin_last = 0,
sc_checkin_itvl = 0, sc_func = 0x0, sc_arg = 0x139, sc_next = {sle_next
= 0x0}}, t_next_wakeup = 0, t_run_time = 313, t_ctx_sw_cnt = 313,
t_os_task_list = {stqe_next = 0x139}, t_os_list = {tqe_next = 0x139,
tqe_prev = 0x139}, t_obj_list = {sle_next = 0x139}}
(gdb) bt
#0 0xfffffffe in ?? ()
#1 <signal handler called>
#2 0x00000000 in ?? ()
#3 0x00000000 in ?? ()
(gdb)
Presumably the gdb session cant persist through reset... so just kill that
and start over
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image confirm
-cserial1
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: ff846c585a34185c24f46166547a6447f1c82de94fe2ab93033dc40903d873b1
slot=1
version: 0.0.0
bootable: false
flags:
hash: 75379446f1c26f11b86f521f06636c0fcd4c28f3b14e192fe3331ba4504330ff
Split status: matching
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr image upload
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/loader/apps/bleprph/bleprph.elf
-cserial1 -t -ldebug
2017/01/17 17:45:16 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:7
Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 0]}
2017/01/17 17:45:16 [DEBUG] Serializing request &{Op:2 Flags:0 Len:7
Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 0]} into buffer [2 0 0 7 0
0 0 1 161 100 101 99 104 111 0]
2017/01/17 17:45:16 [DEBUG] Tx packet dump:
00000000 02 00 00 07 00 00 00 01 a1 64 65 63 68 6f 00
|.........decho.|
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 06 09 |..|
2017/01/17 17:45:16 [DEBUG] Writing [6 9] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 41 42 45 43 41 41 41 48 41 41 41 41 41 61 46 6b
|ABECAAAHAAAAAaFk|
00000010 5a 57 4e 6f 62 77 44 33 7a 51 3d 3d |ZWNobwD3zQ==|
2017/01/17 17:45:16 [DEBUG] Writing [65 66 69 67 65 65 65 72 65 65 65 65 65
97 70 107 90 87 78 111 98 119 68 51 122 81 61 61] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 0a |.|
2017/01/17 17:45:16 [DEBUG] Writing [10] to data channel
2017/01/17 17:45:16 [INFO] Incoming:
00000000 06 09 41 42 45 43 41 41 41 48 41 41 41 41 41 61
|..ABECAAAHAAAAAa|
00000010 46 6b 5a 57 4e 6f 62 77 44 33 7a 51 3d 3d |FkZWNobwD3zQ==|
2017/01/17 17:45:16 [DEBUG] Reading [6 9 65 66 69 67 65 65 65 72 65 65 65
65 65 97 70 107 90 87 78 111 98 119 68 51 122 81 61 61] from data channel
2017/01/17 17:45:16 [DEBUG] Rx packet dump:
00000000 02 00 00 07 00 00 00 01 a1 64 65 63 68 6f 00
|.........decho.|
2017/01/17 17:45:16 [DEBUG] Deserialized response &{Op:2 Flags:0 Len:7
Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 0]}
2017/01/17 17:45:16 [INFO] Incoming:
00000000 0d |.|
2017/01/17 17:45:16 [DEBUG] Reading [13] from data channel
2017/01/17 17:45:16 [INFO] Incoming:
00000000 06 09 41 41 6f 44 41 41 41 41 41 41 41 41 41 64
|..AAoDAAAAAAAAAd|
00000010 68 55 |hU|
2017/01/17 17:45:16 [DEBUG] Reading [6 9 65 65 111 68 65 65 65 65 65 65 65
65 65 100 104 85] from data channel
2017/01/17 17:45:16 [DEBUG] Rx packet dump:
00000000 03 00 00 00 00 00 00 01 |........|
2017/01/17 17:45:16 [DEBUG] Deserialized response &{Op:3 Flags:0 Len:0
Group:0 Seq:0 Id:1 Data:[]}
2017/01/17 17:45:16 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:78
Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 56 127 69 76 70 1 1 1 0 0
0 0 0 0 0 0 0 2 0 40 0 1 0 0 0 189 130 0 0 52 0 0 0 196 239 20 0 2 2 0 5 52
0 32 0 5 0 40 0 23 0 20 0 1 0 0 112 99 108 101 110 26 0 22 132 215 99 111
102 102 0]}
2017/01/17 17:45:16 [DEBUG] Serializing request &{Op:2 Flags:0 Len:78
Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 56 127 69 76 70 1 1 1 0 0
0 0 0 0 0 0 0 2 0 40 0 1 0 0 0 189 130 0 0 52 0 0 0 196 239 20 0 2 2 0 5 52
0 32 0 5 0 40 0 23 0 20 0 1 0 0 112 99 108 101 110 26 0 22 132 215 99 111
102 102 0]} into buffer [2 0 0 78 0 1 0 1 163 100 100 97 116 97 88 56 127
69 76 70 1 1 1 0 0 0 0 0 0 0 0 0 2 0 40 0 1 0 0 0 189 130 0 0 52 0 0 0 196
239 20 0 2 2 0 5 52 0 32 0 5 0 40 0 23 0 20 0 1 0 0 112 99 108 101 110 26 0
22 132 215 99 111 102 102 0]
2017/01/17 17:45:16 [DEBUG] Tx packet dump:
00000000 02 00 00 4e 00 01 00 01 a3 64 64 61 74 61 58 38
|...N.....ddataX8|
00000010 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
|.ELF............|
00000020 02 00 28 00 01 00 00 00 bd 82 00 00 34 00 00 00
|..(.........4...|
00000030 c4 ef 14 00 02 02 00 05 34 00 20 00 05 00 28 00 |........4.
...(.|
00000040 17 00 14 00 01 00 00 70 63 6c 65 6e 1a 00 16 84
|.......pclen....|
00000050 d7 63 6f 66 66 00 |.coff.|
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 06 09 |..|
2017/01/17 17:45:16 [DEBUG] Writing [6 9] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 41 46 67 43 41 41 42 4f 41 41 45 41 41 61 4e 6b
|AFgCAABOAAEAAaNk|
00000010 5a 47 46 30 59 56 67 34 66 30 56 4d 52 67 45 42
|ZGF0YVg4f0VMRgEB|
00000020 41 51 41 41 41 41 41 41 41 41 41 41 41 41 49 41
|AQAAAAAAAAAAAAIA|
00000030 4b 41 41 42 41 41 41 41 76 59 49 41 41 44 51 41
|KAABAAAAvYIAADQA|
00000040 41 41 44 45 37 78 51 41 41 67 49 41 42 54 51 41
|AADE7xQAAgIABTQA|
00000050 49 41 41 46 41 43 67 41 46 77 41 55 41 41 45 41
|IAAFACgAFwAUAAEA|
00000060 41 48 42 6a 62 47 56 75 47 67 41 57 68 4e 64 6a
|AHBjbGVuGgAWhNdj|
00000070 62 32 5a 6d 41 4c 52 39 |b2ZmALR9|
2017/01/17 17:45:16 [DEBUG] Writing [65 70 103 67 65 65 66 79 65 65 69 65
65 97 78 107 90 71 70 48 89 86 103 52 102 48 86 77 82 103 69 66 65 81 65 65
65 65 65 65 65 65 65 65 65 65 73 65 75 65 65 66 65 65 65 65 118 89 73 65 65
68 81 65 65 65 68 69 55 120 81 65 65 103 73 65 66 84 81 65 73 65 65 70 65
67 103 65 70 119 65 85 65 65 69 65 65 72 66 106 98 71 86 117 71 103 65 87
104 78 100 106 98 50 90 109 65 76 82 57] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 0a |.|
2017/01/17 17:45:16 [DEBUG] Writing [10] to data channel
2017/01/17 17:45:16 [INFO] Incoming:
2017/01/17 17:45:16 [DEBUG] Reading [] from data channel
2017/01/17 17:45:16 [INFO] Incoming:
00000000 06 09 41 42 41 44 41 41 41 47 41 41 45 41 41 62
|..ABADAAAGAAEAAb|
00000010 39 69 63 6d 4d 44 2f 32 70 67 |9icmMD/2pg|
2017/01/17 17:45:16 [DEBUG] Reading [6 9 65 66 65 68 65 65 65 71 65 65 69
65 65 98 57 105 99 109 77 68 47 50 112 103] from data channel
2017/01/17 17:45:16 [DEBUG] Rx packet dump:
00000000 03 00 00 06 00 01 00 01 bf 62 72 63 03 ff |.........brc..|
2017/01/17 17:45:16 [DEBUG] Deserialized response &{Op:3 Flags:0 Len:6
Group:1 Seq:0 Id:1 Data:[191 98 114 99 3 255]}
2017/01/17 17:45:16 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:7
Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 1]}
2017/01/17 17:45:16 [DEBUG] Serializing request &{Op:2 Flags:0 Len:7
Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 1]} into buffer [2 0 0 7 0
0 0 1 161 100 101 99 104 111 1]
2017/01/17 17:45:16 [DEBUG] Tx packet dump:
00000000 02 00 00 07 00 00 00 01 a1 64 65 63 68 6f 01
|.........decho.|
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 06 09 |..|
2017/01/17 17:45:16 [DEBUG] Writing [6 9] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 41 42 45 43 41 41 41 48 41 41 41 41 41 61 46 6b
|ABECAAAHAAAAAaFk|
00000010 5a 57 4e 6f 62 77 48 6e 37 41 3d 3d |ZWNobwHn7A==|
2017/01/17 17:45:16 [DEBUG] Writing [65 66 69 67 65 65 65 72 65 65 65 65 65
97 70 107 90 87 78 111 98 119 72 110 55 65 61 61] to data channel
2017/01/17 17:45:16 [INFO] Outgoing:
00000000 0a |.|
2017/01/17 17:45:16 [DEBUG] Writing [10] to data channel
2017/01/17 17:45:16 [INFO] Incoming:
2017/01/17 17:45:16 [DEBUG] Reading [] from data channel
2017/01/17 17:45:16 [INFO] Incoming:
00000000 06 09 41 41 6f 44 41 41 41 41 41 41 41 41 41 64
|..AAoDAAAAAAAAAd|
00000010 68 55 |hU|
2017/01/17 17:45:16 [DEBUG] Reading [6 9 65 65 111 68 65 65 65 65 65 65 65
65 65 100 104 85] from data channel
2017/01/17 17:45:16 [DEBUG] Rx packet dump:
00000000 03 00 00 00 00 00 00 01 |........|
2017/01/17 17:45:16 [DEBUG] Deserialized response &{Op:3 Flags:0 Len:0
Group:0 Seq:0 Id:1 Data:[]}
2017/01/17 17:45:16 [DEBUG] goroutine 1 [running]:
mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420167e10,
0xf, 0xc4202f1b28)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
+0x111
mynewt.apache.org/newt/newtmgr/protocol.DecodeImageUploadResponse(0xc420167dc0,
0x6, 0x8, 0x0, 0x1, 0x0)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/protocol/imageupload.go:98 +0x1c6
mynewt.apache.org/newt/newtmgr/cli.imageUploadCmd(0xc42016f680,
0xc420014400, 0x1, 0x4)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/cli/image.go:362 +0x4e0
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016f680,
0xc4200143c0, 0x4, 0x4, 0xc42016f680, 0xc4200143c0)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
+0x443
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42016e000,
0xc42016eb40, 0xc42016e240, 0xc420166f90)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
+0x367
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc42016e000,
0x40d65bc, 0xc4200001a0)
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
+0x2b
main.main()
/Users/jacobrosenthal/dev/go/src/
mynewt.apache.org/newt/newtmgr/newtmgr.go:25 +0x2f
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1
goroutine 20 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
os/signal.loop()
/usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.1
/usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:28 +0x41
Error: Target error: 3
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$
On Mon, Jan 16, 2017 at 3:35 PM, Christopher Collins <cc...@apache.org>
wrote:
> 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 <
> ccollins@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 <
> > > jakerosenthal@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 <
> > > jakerosenthal@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 <
> > > ccollins@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
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > >
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
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 <cc...@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 <
> > jakerosenthal@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 <
> > jakerosenthal@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 <
> > ccollins@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
> > > >>>
> > > >>
> > > >>
> > > >
> >
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
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 <cc...@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 <
> jakerosenthal@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 <
> jakerosenthal@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 <
> ccollins@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
> > >>>
> > >>
> > >>
> > >
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
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 <ja...@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 <ja...@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: 21439de02cbf31626856374f44cbd490fd6def3ce3062b63d55ed2c19a8b
> >> 2b83
> >> slot=1
> >> version: 0.0.0
> >> bootable: false
> >> flags:
> >> hash: 8b64ea89bf0495c0ccb25b96b3a7f06fd5e540e221f9659f9bc6b0d0d303
> >> 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 <ccollins@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
> >>>
> >>
> >>
> >
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
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 <ja...@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 <ja...@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: 21439de02cbf31626856374f44cbd490fd6def3ce3062b63d55ed2c19a8b
>> 2b83
>> slot=1
>> version: 0.0.0
>> bootable: false
>> flags:
>> hash: 8b64ea89bf0495c0ccb25b96b3a7f06fd5e540e221f9659f9bc6b0d0d303
>> 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 <ccollins@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
>>>
>>
>>
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
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 <ja...@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: 21439de02cbf31626856374f44cbd490fd6def3ce3062b63d55ed2c19a8b2b83
> slot=1
> version: 0.0.0
> bootable: false
> flags:
> hash: 8b64ea89bf0495c0ccb25b96b3a7f06fd5e540e221f9659f9bc6b0d0d303d6f1
> 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 <cc...@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
>>
>
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
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: 21439de02cbf31626856374f44cbd490fd6def3ce3062b63d55ed2c19a8b2b83
slot=1
version: 0.0.0
bootable: false
flags:
hash: 8b64ea89bf0495c0ccb25b96b3a7f06fd5e540e221f9659f9bc6b0d0d303d6f1
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 <cc...@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
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
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
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
OK.. Thanks so much for keeping on this with me.
Im on nrf51dk-16kbram, so I swapped to that. Based on your numbers Id
still be running out of ram for the so I shrunk MSYS_1_BLOCK_SIZE as has
been discussed:
MSYS_1_BLOCK_SIZE: 76
text data bss dec hex filename
4936 112 15024 20072 4e68
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/apps/splitty/splitty.elf
Size of Loader Image: loader
110364 1172 10920 122456 1de58
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/loader/apps/bleprph/bleprph.elf
Looks better, but newtmgr image list seems to be hanging or timing out...
so I enable the shell
STATS_NEWTMGR: 0
CONFIG_NEWTMGR: 0
SHELL_TASK: 1
LOG_CLI: 1
text data bss dec hex filename
1424 0 15104 16528 4090
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/apps/splitty/splitty.elf
Size of Loader Image: loader
112356 1268 11048 124672 1e700
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/loader/apps/bleprph/bleprph.elf
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?
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?
Thanks again. As Im sure you know, Hardly anyone else has a ble stack, and
nobody else's configures for 16kb targets, so this is pretty amazing.
On Thu, Jan 12, 2017 at 10:03 AM, Christopher Collins <cc...@apache.org>
wrote:
> On Mon, Jan 09, 2017 at 10:48:48AM -0800, Christopher Collins wrote:
> > The boot sequence and upgrade procedure for the split image setup is a
> > bit complicated. I have been working on some documentation for this
> > area, but haven't quite finished it. I hope to have something ready in
> > a day or two. In the meantime, please feel free to ask any follow up
> > questions.
>
> FYI - The split image documentation has been updated on the Mynewt site:
> http://mynewt.apache.org/latest/os/modules/split/split/
>
> Chris
>
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
On Mon, Jan 09, 2017 at 10:48:48AM -0800, Christopher Collins wrote:
> The boot sequence and upgrade procedure for the split image setup is a
> bit complicated. I have been working on some documentation for this
> area, but haven't quite finished it. I hope to have something ready in
> a day or two. In the meantime, please feel free to ask any follow up
> questions.
FYI - The split image documentation has been updated on the Mynewt site:
http://mynewt.apache.org/latest/os/modules/split/split/
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
On Sun, Jan 08, 2017 at 01:04:54PM -0700, Jacob Rosenthal wrote:
> On Mon, Jan 2, 2017 at 2:46 PM, Christopher Collins <cc...@apache.org>
> wrote:
>
> > Do you know how big your loader is currently?
>
>
> Well, could be anything based on how much Im trying to strip from the
> nimble stack at any given time. but Im generally fighting to fit it within
> one slot which on the nrf51 is 110kB.
Yeah, it is currently pretty tough to get the OS + BLE stack to fit in
110kB. Hopefully we'll get a chance to reduce the size of NimBLE soon.
> I'm also not sure if it would buy
> > you much extra flash space.
>
> At this point Its not even about buying space, as I now have my other 110Kb
> back from the second image slot.. What I dont have anymore is update
> capability, so its about restoring that capability.
>
>
> > Im somewhat unclear if the 'loader' app can/should also serve as the
> > 'bootloader', or if it was intended that a separate bootloader would also
> > be present in addition to loader and application?
> >
> > This question of mine got buried above.. in this scenario, the distinction
> between loader and bootloader gets weird... My thought is theyre merged?
Sorry, I must have missed that question. The boot loader is present in
the split image setup. Here is how the boot sequence would look for the
various image setups:
1. Single image
* no boot loader
* image at address 0
* hardware boots directly into image
2. Stub image
* boot loader at address 0
* hardware boots into boot loader
* boot loader jumps to image in slot 0
3. Unified image (dual bank)
* boot loader at address 0
* hardware boots into boot loader
* if required, boot loader swaps images in the two image slots
(i.e., if an upgrade or a fallback is being performed).
* boot loader jumps to image in slot 0
4. Split image
* boot loader at address 0
* hardware boots into boot loader
* if required, boot loader swaps images in the two image slots
(i.e., if an upgrade or a fallback *between two loaders* is being
performed).
* boot loader jumps to image in slot 0
* loader in slot 0 jumps to "app" in slot 1.
The boot sequence and upgrade procedure for the split image setup is a
bit complicated. I have been working on some documentation for this
area, but haven't quite finished it. I hope to have something ready in
a day or two. In the meantime, please feel free to ask any follow up
questions.
Thanks,
Chris
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Jacob Rosenthal <ja...@gmail.com>.
On Mon, Jan 2, 2017 at 2:46 PM, Christopher Collins <cc...@apache.org>
wrote:
> Do you know how big your loader is currently?
Well, could be anything based on how much Im trying to strip from the
nimble stack at any given time. but Im generally fighting to fit it within
one slot which on the nrf51 is 110kB.
I'm also not sure if it would buy
> you much extra flash space.
At this point Its not even about buying space, as I now have my other 110Kb
back from the second image slot.. What I dont have anymore is update
capability, so its about restoring that capability.
> Im somewhat unclear if the 'loader' app can/should also serve as the
> 'bootloader', or if it was intended that a separate bootloader would also
> be present in addition to loader and application?
>
> This question of mine got buried above.. in this scenario, the distinction
between loader and bootloader gets weird... My thought is theyre merged?
Re: Single Bank firmware update (ie nordic vendor style dfu)
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
On Sun, Jan 01, 2017 at 11:10:01PM -0700, Jacob Rosenthal wrote:
> On low flash devices like nrf51822 FLASH_AREA_IMAGE_1 equal to
> FLASH_AREA_IMAGE_0 is improbable, which means dual bank is likewise
> improbable and as a result we've talked previously about how to shrink
> FLASH_AREA_IMAGE_1 down to a stub.
>
> However, my current understanding is newtmgr/imagemgr implementation is
> dual bank, wherein the application saves received bytes into
> COREDUMP_FLASH_AREA (ie FLASH_AREA_IMAGE_1) and reboots allowing bootloader
> (apps/boot) to safely make the swap.
Your understanding sounds correct to me. If you don't have enough flash
for a second image slot, then image upgrade isn't possible.
Just a clarification- for a split image, both slots don't need to be
exactly the same size; the slot sizes just need to meet these
requirements:
* Both slots are large enough to accommodate the loader.
* Second slot is large enough to accommodate the app.
In other words, if your app is larger than your loader, you only need to
budget for the extra space in the second slot. Unfortunately, I don't
think this allowance helps in your case. I think the problem you're
facing is that the loader (kernel + BLE stack) is too large.
> I don't believe theres a good way to do a single bank receive from within
> the running application, which would mean this has to be moved into the
> bootloader, which means it need to share access to nimble, which means a
> bootloader fork that includes splitty, nimble, newtmgr, imagemgr.
>
> Im somewhat unclear if the 'loader' app can/should also serve as the
> 'bootloader', or if it was intended that a separate bootloader would also
> be present in addition to loader and application?
>
> Thoughts on this architecture, am I missing anything?
Hmm... I do see what you mean, but that sounds like a pretty fundamental
change to how image management works. I'm also not sure if it would buy
you much extra flash space. The boot loader is already fairly stripped
down, and it doesn't contain much code that could be shared by the image
upgrade mechanism.
I don't want to be dismissive of your idea, but my thinking is that the
best way forward is to try to reduce the size of the BLE stack. This is
something that has been on the radar for quite a while. We haven't
really looked at this at all, so there is probably some easy savings to
be had. I have been meaning to do a quick survey of the BLE host to
determine what is contributing to its code size. That said, if you want
to look at incorporating upgrade functionality into the boot loader,
don't let me stop you :).
Do you know how big your loader is currently?
Thanks,
Chris