Programming manufacturing data during production

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

During production, we want to be able to program some manufacturing data (serial number, etc) to the BLE module. We could do this with a UART interface (or another serial interface), but I wanted to see if it's possible to perform action after the firmware download sequence using the HCI UART. I may have read another post about this possibility (and it may have stated that it wasn't possible) but I can't find this post anymore and so wanted to ask.

If it's not possible to customize the HCI UART at all to do this manufacturing data programming, would it instead be possible to add memory sections to a linker file so that it has a memory location that can contain manufacturer data. Then, after generating the hex file, overwrite this static memory location with the manufacturer data? (The application code would read from this memory location on start up to fill the manufacturer data.) It seems like it might be possible since this post:

Programming the 20732S MODULE USING 2073xTAG Board

talks about how the "BD_ADDR" should always be at offset Byte 21, and that the following 6 bytes can be modified (in the HEX file) to change the BD ADDR for a subsequent device.

The question probably is whether or not we developers have access to a linker file to specify this static memory location.

Thanks,

Mike

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

The linker memory map only applies to the execution region (the RAM) and not the load region (the NV storage). Unlike traditional load regions in the .elf, we remap them to NV, so linker symbols will not help you get to the data in NV at runtime. You have to use known/fixed offsets that are not used by the FW for storage.

Firmware security (20732) is probably what you are looking for. The .hex file that is downloaded to NV by the download tools in the SDK uses Intel hex format. So if you do have unique serial number etc to burn during factory programing, you should be able to edit the hex file (with appropriate tools) to insert this data in the location where you need it to be and then use chipload to download this new hex file.

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

I will talk to the developers and see if they can respond.

At this point, the blog you referenced is probably the best data we have for production programming.

j.t arvinds

0 Likes

Along the lines of production programming, there is some confusion with regards to the Reset_N and the Uart_rx jumper and how these affect "programming" and "application startup".  Does the power on transition perform a system reset or do we absolutely need a reset button to start the App?"

18    RESET_N    I/O    PU    VDDO     Active-low system reset with open-drain output & internal pull-up resistor

The presumption has been that if our RESET pin is not connected to anything the reset pin will go high on power up.  But if toggling low provides a reset, it doesn't say if we need to toggle it or if the reset is provided automatically on startup.  The way the development kit works is we load the program, throw a switch, then push the RESET button to start the APP.   There is just not enough detail in the documentation for us to incorporate it in our schematic.  Any help on this would be appreciated.

0 Likes

When sampled on RESET only:

HCI UART Rx = High (Programming mode)

HCI UART Rx = Low (Application mode)

> Does the power on transition perform a system reset or do we absolutely need a reset button to start the App?"

There is an internal power-on-reset circuit in the chip which will reset and power it on when the input supply crosses the threshold. The reset button is not a requirement, but is there in the tag boards to make it easy to reset the chip during development. If this signal is pulled low, the chip will be remain in reset for as long as the line is asserted low.

> The way the development kit works is we load the program, throw a switch, then push the RESET button to start the APP......

You can turn off dip switch 2 on SW4 and power on the device too (over USB or the battery) and it will still initialize the app.

Thank you ! That was helpful

0 Likes
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

The linker memory map only applies to the execution region (the RAM) and not the load region (the NV storage). Unlike traditional load regions in the .elf, we remap them to NV, so linker symbols will not help you get to the data in NV at runtime. You have to use known/fixed offsets that are not used by the FW for storage.

Firmware security (20732) is probably what you are looking for. The .hex file that is downloaded to NV by the download tools in the SDK uses Intel hex format. So if you do have unique serial number etc to burn during factory programing, you should be able to edit the hex file (with appropriate tools) to insert this data in the location where you need it to be and then use chipload to download this new hex file.

Anonymous
Not applicable

Hi Arvind,

I'm attempting to go through the steps needed in order to add a serial number to the HEX file. This post and the one referenced above (regarding Firmware Security) give good information, but I was hoping you could add some more detail.

I've built the hex file using the SDK and can see how the first 40 bytes are used, as mentioned in the other post. You mention that I can edit this hex file to enter the serial number, but can you give me a more concrete example of how to edit the hex file and then how to read the EEPROM in the application code?

So for example, if I want to put the serial number after the 40 bytes, can I just enter the serial number after the 40 bytes (and also changing the number of bytes in that line as well)? Then do I use the function "bleapputils_eepromRead(...)" or maybe "bleappfwu_readMem(...)"?

When I look at the bleapputils.h file, it shows how to set a custom area offset and length. Is that necessary?

(I did try using that function, but it seems to read from EEPROM address 0xFF001C00, regardless of changing the bleapputils_eepromCustAreaOffset value - although I may have used it wrong).

Thanks,

Mike

0 Likes

The hex file is in Intel hex format (Intel HEX - Wikipedia, the free encyclopedia). So you cannot hand-edit it trivially like you would a text file. I believe there are free/open source tools that let you edit Intel hex files. Or you can write Perl (or other similar) scripts to do the same. The main idea is to insert another hex record into the hex file at the location you want to write to.

The factory image (which is what is downloaded by the SDK) has a constant offset of 0xFF000000 to the physical offset of the NV (always 0x00 for now). The OTA (or PUART) update image is always at 0x00 (but I guess you will not need this security field in the OTA image). So if you want to put say 16 bytes of security info at offset 0x64 in the EEPROM, include a hex record at 0xFF000064 with these 16 bytes of data. The chiploader will write and verify this block of data too. If you are using serial flash, you have to put this in its own sector so OTA/PUART upgrade will not erase that sector.

When reading, you can use bleappfwu_readMem(), but remember to offset by 0xFF000000 for EERPOM or 0xF8000000 for serial flash. See ws_upgrade.c for an example.