Hi Marcos, > On Jan 23, 2017, at 8:34 AM, Marcos Scheeren <[email protected]> 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!
