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
### Package: targets/jacob-nrf52dk
pkg.name: "targets/jacob-nrf52dk"
pkg.type: "target"
pkg.description:
pkg.author:
pkg.homepage:
pkg.deps:
- mgmt/newtmgr/transport/nmgr_shell
syscfg.vals:
STATS_NEWTMGR: 0
CONFIG_NEWTMGR: 0
SHELL_TASK: 1
LOG_CLI: 1
LOG_LEVEL: 255
BLE_LL_CFG_FEAT_LE_ENCRYPTION: 0
BLE_SM_LEGACY: 0
MSYS_1_BLOCK_COUNT: 8
MSYS_1_BLOCK_SIZE: 76
BLE_LL_NUM_SCAN_DUP_ADVS: 0
BLE_LL_NUM_SCAN_RSP_ADVS: 0
BLE_LL_WHITELIST_SIZE: 0
BLE_LL_RESOLV_LIST_SIZE: 0
### Target: targets/jacob-nrf52dk
target.app: "@apache-mynewt-core/apps/splitty"
target.bsp: "@apache-mynewt-core/hw/bsp/nrf51dk-16kbram"
target.build_profile: "optimized"
target.loader: "@apache-mynewt-core/apps/bleprph"
