Program board without J-Link/OpenOCD.

[Marcos Scheeren <ma...@infinitoom.com>]

Hi,


I'm using a Black Magic Probe to program my nRF51822xxAA 16k RAM based
boards, (which all worked well with the Nordic SoftDevice and RIOT OS).
After a lot of hacking and fiddling I got the Blinky example and
Console/Shell over UART running.

The issue is that the BMP connects to the board via GDB extended-remote
mode and it seems that I don't have direct flash write access, so using the
GDB "restore" command won't work to write raw binaries to flash. Although I
can use .hex and .elf files using "load" command and .bin files with
"exec-file" command.

For the Blinky and UART to work, I used gcc objcopy to convert the
"create-image" generated .bin so the GDB accepts it (not sure if really
necessary, but it worked). And so far, I can't use the .img file. And also,
when I tried the same with more complex examples that use the BLE stack,
the board doesn't even booted.

To my understanding, the newt create-image command outputs an .img with the
bootloader sector, the sectors headers, and the two application sectors,
needed for the bootloader to properly locate, identify and load the
applications.

And my "low-level bootloader knowledge" ends here :( So the questions are:

- Are there any ways to output a single .elf or .bin file already with the
sectors headers (maybe convert the .img file) so I can load it using the
GDB extended-remote mode? Or that would require further work, like changing
the newt golang sources?



Thanks.
Other than that, really appreciate the architecture of the OS!

Re: Program board without J-Link/OpenOCD.

[Christopher Collins <cc...@apache.org>]

Hi Marcos,

I don't know if I can solve this problem, but I can at least answer a
few of your questions.  Hopefully someone more knowledgeable can fill in
the gaps.

On Mon, Jan 23, 2017 at 02:34:11PM -0200, Marcos Scheeren wrote:
[...]
> To my understanding, the newt create-image command outputs an .img with the
> bootloader sector, the sectors headers, and the two application sectors,
> needed for the bootloader to properly locate, identify and load the
> applications.

The .img file only contains:
    * image header
    * image binary

The contents of a .img file occupy a single image slot.  The boot loader
slot and the second image slot are untouched when you upload an image.

A .img file, as opposed to a .bin file, is only useful if you are using
the boot loader.  The boot loader knows how to read the image header and
determine where the image executable actually begins.  If you aren't
using a boot loader, then you need to upload a .bin file to address 0 so
that the hardware jumps straight into the image on boot.  This process
is minimally described here:
https://mynewt.apache.org/latest/os/modules/split/split/

> And my "low-level bootloader knowledge" ends here :( So the questions are:
> 
> - Are there any ways to output a single .elf or .bin file already with the
> sectors headers (maybe convert the .img file) so I can load it using the
> GDB extended-remote mode? Or that would require further work, like changing
> the newt golang sources?

That sounds like a manufacturing image.  A manufacturing image contains
the entire contents of a device's flash; it is intended to be built into
every unit during the early stages of manufacturing.  In particular, a
manufacturing image contains:
    * boot loader
    * image in slot 0
    * (optional) image in slot 1 or split image
    * (optional) user data

There is some basic documentation for creating mfg images here:
http://mynewt.apache.org/latest/newt/command_list/newt_mfg/

This process should definitely work, as we use it frequently.  However,
the documentation may be lacking, so please don't hestitate to follow up
with questions.

> Thanks.
> Other than that, really appreciate the architecture of the OS!

Chris

Re: Program board without J-Link/OpenOCD.

[marko kiiskila <ma...@runtime.io>]

Hi Marcos,

> On Jan 23, 2017, at 8:34 AM, Marcos Scheeren <ma...@infinitoom.com> wrote:
> 
> I'm using a Black Magic Probe to program my nRF51822xxAA 16k RAM based
> boards, (which all worked well with the Nordic SoftDevice and RIOT OS).
> After a lot of hacking and fiddling I got the Blinky example and
> Console/Shell over UART running.
> 
> The issue is that the BMP connects to the board via GDB extended-remote
> mode and it seems that I don't have direct flash write access, so using the
> GDB "restore" command won't work to write raw binaries to flash. Although I
> can use .hex and .elf files using "load" command and .bin files with
> "exec-file" command.

in that case ‘restore’ should work also. What ‘load’ and ‘restore’ both do is
they create write requests writing the source data to specified location in memory.
‘load’ decodes the elf headers (or a.out or others) to get to source data
and where it should go. With restore, you have to tell it where to write.
‘help restore binary’ on gdb prompt tells the command line options.

gdb (or gdb server) is then supposed to map the writes to appropriate
operation for the target (flash write or ram write) depending on address
write is destined to.

Do you have your own hw/bsp?

> For the Blinky and UART to work, I used gcc objcopy to convert the
> "create-image" generated .bin so the GDB accepts it (not sure if really
> necessary, but it worked). And so far, I can't use the .img file. And also,
> when I tried the same with more complex examples that use the BLE stack,
> the board doesn't even booted.

This should, indeed, not be necessary. Maybe the failure with more complex
code is not due to loading issue :P

> To my understanding, the newt create-image command outputs an .img with the
> bootloader sector, the sectors headers, and the two application sectors,
> needed for the bootloader to properly locate, identify and load the
> applications.

create-image reads in .bin file, and only adds checksum, and image header data
to it.
It does not include bootloader in the target. Bootloader is built separately, and loaded
separately. However, given that you see ‘blinky’ working, I assume that you
got a lot of things going already.
Note that bootloader is optional, you only need it if you want to support
firmware upgrades either over the air, or over serial port. Otherwise you can
just make the start address of the flash region in your linker script to be 0x000,
_imghdr_size to be 0 and load the .bin file. 

> And my "low-level bootloader knowledge" ends here :( So the questions are:
> 
> - Are there any ways to output a single .elf or .bin file already with the
> sectors headers (maybe convert the .img file) so I can load it using the
> GDB extended-remote mode? Or that would require further work, like changing
> the newt golang sources?

You probably don’t need to modify newt for things. If there is a need to
do some additional things that need to happen to binary, you can always do
that in the downloader. As you’ve seen, these are shell scripts currently,
and you presumably do get enough data passed in as environment variables
to figure out where to get the binary, and where it should be loaded.



> 
> 
> Thanks.
> Other than that, really appreciate the architecture of the OS!