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.
1 of 1 people found this helpful
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.
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
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).
1 of 1 people found this helpful
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.