arm-gcc hex file header question

koolatron
Posts: 4
Joined: Sat Apr 09, 2016 9:21 am

arm-gcc hex file header question

Postby koolatron » Sun Apr 10, 2016 11:35 pm

Hi guys,

I've been busy getting the OSHChip working with an arm-gcc toolchain and openocd for debugging using Eclipse, but I've run into something odd that I'd like some external input on. The example hex files in the OSChip_related_files repository program correctly using the drag-and-drop functionality that the cmsis_dap_1.0 programmer exposes. However, it ignores hex files generated by arm-gcc.

I tracked this down to the fact that the example hex files include a header that apparently identifies them to the programmer:

:020000040000FA

If I add that header to my arm-gcc generated hex files, the programmer grabs them and programs the OSHChip correctly (and they work!). However, I have absolutely no idea where this header comes from or why it's needed. As these are part of the OSHChip github, I'm guessing that these were generated by Keil, which might have some special magic baked in, but I feel that is rather unlikely. Any ideas?

EDIT: Some further research turns up that this isn't actually a header, but an Intel Hex directive that extends the format's address space from 16 to 32 bits using a supplied offset. It makes sense why objcopy wouldn't prefix it here, since the start address of my program is below 0x00010000. I assume it's within spec to not emit it in this case. Still, I wonder why the programmer won't take it without this directive.

User avatar
Philip
Posts: 12
Joined: Sun Jan 24, 2016 9:02 am

Re: arm-gcc hex file header question

Postby Philip » Thu Apr 14, 2016 11:10 am

First, I don't know what is causing the issue you are seeing, because at least for hex files that don't have anything beyond
0x0001 0000 , the Extended Linear Address record (04) should not be needed.

FYI, the parsing of the .HEX file is done in this function (running within OSHChip_CMSIS_DAP_V1.0)
https://github.com/xiongyihui/CMSIS-DAP ... intelhex.c
At line 141 is where this :020000040000FA record is handled.

Ahhhh.... I think I found the problem:

The way this works is that a program called the "Flash Algorithm" is loaded into RAM on the nRF51822
https://github.com/xiongyihui/CMSIS-DAP ... et_flash.c
(line 93)
#define MIN_RAM_ADDRESS 0x20000000

See, line 56 of this file:
https://github.com/xiongyihui/CMSIS-DAP ... ash_blob.h

Then in target_flash.c line 97 , the algorithm (program in RAM in nRF51822) is started, and it then waits for
blocks of data to be written to RAM, which it the writes to FLASH. I am guessing this is more efficient than
writing blocks of FLASH directly by SWD.

The "Flash Algorithm" initialization process is called from
https://github.com/xiongyihui/CMSIS-DAP ... user_msc.c
at line 173

Around this point, I kinda got lost, but here's what I suspect may be happening: the 32 bit memory address being
used in the SWD commands gets set to 0x2000xxxx for the flash algorithm to be written to RAM in the nRF51822.
If you don't have the :020000040000FA record, it doesn't get reset back to 0x0000xxxx , which then causes the
problem you are seeing. Thanks for motivating me to go for a dig through this code, it has been on my to-do
list for quite a while.

(in the following, SD is a Soft Device like S130)

Also worth noting, in target_flash.c at line 139 , there is some special case code for a write to address
0x00000000 . It triggers the whole chip erase function. So this is how you can write the SD (which has to go
to address 0x00000000) and then later write the application program that lives above it, and even re-write
it without disturbing the SD. What this means is that if you were creating an application (like blinky)
that doesn't need the SD, your linker script must output the code block that goes to address 0x00000000
first, and then the rest. Typically you would do this anyway, but since .HEX could theoretically have
different Flash sections in a jumbled order, I thought I would note this warning.

You are correct that test/example the .HEX files for OSHChip on github were created with Keil.

In other news, you posted another question "Configuring OpenOCD for use with OSHChip" about your on-going
efforts to get GCC, Ubuntu, OpenOCD, and Eclipse working with OSHChip. I would be delighted to host your
efforts more formally in the github/oshchip directory tree in its own repository.

Please email me directly: philip@oshchip.org


Return to “Compilers”

Who is online

Users browsing this forum: No registered users and 1 guest