12. OTP Programmer

The ‘OTP Programmer’ tool is used for burning the OTP Memory and OTP Header. By visualizing and testing the OTP image while still under development, it helps increasing productivity and avoiding fatal mistakes of erroneously programming the OTP header flags. ‘OTP Programmer’ consists of three sub tools: the ‘OTP Image’, ‘OTP Header’ and the ‘OTP NVDS’.

12.1. OTP Image

This OTP tool enables downloading the default firmware into the SysRAM and burning the OTP memory with a user-defined .hex/.ihex/.bin file. The following picture shows the OTP Image tab:

../_images/otp_image_680_loadfile_memory.png

Figure 33 OTP Image tab

On the left side of the OTP Image tab, the user is able to select the Intel hex or binary file to be downloaded to the OTP Memory. If an Intel hex file is selected, it is parsed and its contents are presented in the Data File Contents table. If a binary file is selected, the table remains empty, but a log message indicates that the file has been read along with its size in bytes.

On the right side of the OTP Image tab, the OTP Memory contents are shown. There are 3 actions associated with it:

Connect: As a first step before reading memory contents and burning the OTP memory, the user has to establish connectivity with the Development Kit by pressing the ‘Connect’ button and waiting for the ‘Press the reset button’ action message to appear on the log. Similarly to UART Booter, the user has 15 seconds to press the reset button to download the default firmware file to the chip. If a ‘CRC does not match’ shows up, please press the ‘Connect’ button again and then the hardware reset button on the board to restart the download process.

Read: After successfully downloading the firmware file to the chip, the user can press the ‘Read’ button to read the OTP memory.

Burn: If a file has been selected for downloading, the user can press the ‘Burn’ button to burn the OTP memory with it. Before performing the actual burn action the following check is made for DA1468x, DA14585/6 and DA1469x family chips. SmartSnippets™ Toolbox checks if the memory segment the user is attempting to burn already contains data. The check is performed on a word level. For DA1468x and DA14585/6 family chips, a word has 8 bytes length and contains data when its value is different than 0x00 while for DA1469x chips a word has 4 bytes length and contains data when is value is different than 0xFFFFFFFF. There are three cases during OTP burn when comparing each one of the words we are trying to burn with the respective words already writeen in OTP memory (described for DA1468x and DA14585/6 family chips for which zeroes is the empty value):

  1. The word we are trying to burn to OTP memory includes zeroes and the respective word in OTP memory is non-zero: No action is taken.
  2. The word we are trying to burn to OTP memory includes non-zeroes and the respective word in OTP memory is non-zero and the contents of the two words do not match. The word is replaced with zero and a warning shows up in log window. If addresses of the words that are replaced with zero are too many a file called ‘not_written_words.txt’ is created in settings file’s directory or under ‘Command_Line_Logs’ in case of CLI. This file contains all the addresses that cannot be written.
  3. The word we are trying to burn to OTP memory includes non-zeroes and the respective word in OTP memory is non-zero and the contents of the two words are the same.Word is replaced with zero silently.

For DA1469x family chips the same checks are performed with the difference that the empty value and the value with with which OTP words are replaced, if required, is 0xFFFFFFFF.

../_images/otp_not_written_warning.png

Figure 34 Warning when writing zeroes on non-zero memory location

After a burn action, a read action is automatically performed in order to refresh the memory contents with the new data. Note that for DA1468x-00 chips, burn action is by default disabled, unless “ENABLE_OTP_BURN_68xAD” property is set to true in properties file. When a DA14583-00 chip is selected, the user has the option to automatically burn “Advanced Bootloader Offset and Length” Header field with the offset and length of the custom bootloader burned in OTP via the OTP Image. A popup dialog requests for permission to burn the header field:

../_images/da145883OtpImage.png

Figure 35 Request permission to burn the header field

Burn action also checks if part of OTP Header will be written. If true then the following warning pops up:

../_images/otp_write_part_header.png

Figure 36 Proceed write OTP Header

Save: By pressing Save, the user has ability to save otp memory contents to a file. A file chooser dialog will popup, in order for the user to select the output file for OTP memory.

The ‘Offset in OTP Memory’ field allows the user to enter the offset (in hex number of bytes) from which a read or burn action starts.

The cells in DA14580/581/583 and DA1468x chips are ‘One Time Programmable’ which means that they are un-programmed when containing a logic 0 level. After programming they will become logic 1.

12.2. OTP Header

The ‘OTP Header’ tool is used for burning the OTP header. Before burning, it validates every header field to ensure that the OTP header is correctly programmed, avoiding in this way fatal mistakes which could damage the chip.

A view of the OTP Header for DA14580/581/583 family chips:

../_images/otp_header_580_read_from_memory.png

Figure 37 OTP Header of a DA14580/581/583 family chip

A view of the OTP Header for DA1468x family chips:

../_images/AE_chip_Header.png

Figure 38 OTP Header of a DA1468x family chip

A view of the OTP Header for DA14585/6 family chips:

../_images/585_chip_Header.png

Figure 39 OTP Header of a DA14585/6 family chip

A view of the OTP Header for DA1469x family chips:

../_images/69x_chip_Header.png

Figure 40 OTP Header of a DA1469x family chip

As shown above, the ‘OTP Header’ tool mainly consists of a table that allows the user to view and edit the value of each header field. Note that some fields are read-only; double-clicking on them has no effect. Editing is performed by choosing a value from the dropdown menu or by double-clicking and setting the desired value in the input field.

Furthermore, some fields marked with yellow-mark-header are fields that user should not change their value or else there is great risk of destroying the chip. Program will warn user if he is going to change the value of such fields.

../_images/protected_fields_warning.png

Figure 41 Warning popup when user tries to burn over protected field.

While addresses marked with red-mark-header are special addresses where the value is stored twice in each original and complement value, alternatively word by word.

The values are hexadecimal values with size equal to the one shown at the ‘Size (words)’ column of the table. For DA14580/581/583 and DA1469x chip families fields are all 4 bytes (4-byte word). For DA1468x and DA14585/6 chip family fields are usually 8 byte, but there are some with more than 8 bytes.

For fields with more complex configuration logic involved, a edit_cell_icon icon is displayed when mouse hovers them. When the user clicks on this icon a suitable interface pops up to edit the configuration.

Some examples of multivalued fields are:

Cache Architecture Settings on address 0x7F8EA28 of DA1468x chips:

../_images/cache_architecture_680.png

Figure 42 Cache Architecture Settings

Serial Configuration Mapping on address 0x7F8EA30 of DA1468x chips:

../_images/serial_configuration_mapping_680.png

Figure 43 Serial Configuration Mapping

Type of fields for DA14580/581/583 chip family:

In DA14580/581/583 chips there are two types of fields:

  1. ‘Integer’: field is treated as an integer, which means that if the user enters fewer hex values than expected according to field size the value is patched with leading zeroes before burning it to the OTP memory (e.g. ‘14580’ becomes ‘00014580’ for a 1-word field). For ‘integer’-type fields, the least significant byte of a word is stored in the smallest address (little-endian). E.g. if a user types 0A0B0C0D for field ‘DMA Length’, 0x0A will be written at 0x47FFB and 0x0D will be written at 0x47FF8.
  2. ‘String’: field is treated as a string, which means that if the user enters fewer hex values than expected according to field size the value is patched with trailing zeroes before burning it to the OTP memory (e.g. ‘14580’ becomes ‘14580000’ for a 1-word field). For ‘string’-type fields, the most significant (left-most) byte of a word is stored in the smallest address (big-endian). E.g. if a user types 0A0B0C0D for field ‘Device Unique ID’, 0x0A will be written at 0x47FD4 and 0x0D will be written at 0x47FD7.

Most of the fields that contain combo boxes cannot be programmed more than once. For example if ‘RC32KHz’ (hex value 0xAA) has been burned as the 32KHz source, it is not allowed to overwrite it with the ‘XTAL32KHz’ value (hex value 0x00). In such a case, the combo boxes are disabled to avoid confusion.

Type of fields for DA1468x, DA14585/6 and DA1469x chip families:

  1. ‘Integer’: The same as for DA14580/581/583 chips. Integer fields are treated as little endian, meaning that they are reversed when burned to OTP memory and also that the value read to OTP memory is reversed and then presented to the OTP header table.
  2. ‘String’: The same as DA14580/581/583 chips. String fields are treated as big endian, meaning that a value is burned to the OTP memory exactly as it is presented in the OTP Header.
  3. ‘Flag’: Fields of type ‘Flag’ are represented as dropdown lists where the user selects the desired value.
  4. ‘Protected’: Only DA1468x header contains protected fields. There are two fields that are of type ‘Protected’ in DA1468x header, Trim and calibration values (read-only) and ECC image length (writable). These fields are treated as integers. From the 8 bytes of ‘ECC Image Length’ 4 bytes contain the value and the other 4 bytes contain the reverse value. This is for security reasons. Each time value is read it is checked with the reverse value of the rest of the field to see that the value read match. In write, the reverse value is produced and stored with the real value. The other field ‘Trim and calibration values’ which is read-only consists of 384 bytes. These bytes are split in 8 bytes each of which consists of 4 byte value and 4 byte reverse value as it explained above. These bytes store the ‘trim or calibration’ address and its value next to it. You can see this table clicking on the edit_cell_icon. When user edits a ‘protected’ field it enters only the value part. That’s why ‘ECC image length’ for example asks for 8 byte and not 16 byte value. The reverse of the user entered value is produced automatically and stored on the other 8 bytes of the field.

12.2.1. Configuration Script (CS) in OTP

OTP Header of DA1469x chips includes the “Configuration Script” field. If the user presses the button that is visible on the value column of the table when user mouses over the Configuration Script row, the configuration script value is parsed and the commands it contains are presented in the following popup dialog (Figure 39):

../_images/csInOtp.png

Figure 44 Manage Configuration Script dialog

The user can append commands after the last CS command that has been read from the OTP memory, if the STOP command has not been added to the end of the CS. The commands that have been burned to the OTP memory are highlighted in light yellow color. The highlighted commands cannot be modified. Note that a valid CS should start with the Start command (0xA5A5A5A5). Each CS command consists of one or more words. The CMD number is the command identifier. Rows with the same CMD number belong to the same command. The 2nd column indicates the address of the command word and the 3rd column indicates the value of each command word. By looking at the 4th column, user can see the type and a small description of the command. In order to add a new command, the user has to select the type of the command and where this command should be placed in the CS and press the Add button. By default a new command is added at the end of the CS commands’ table. Available command types are: Start, Stop, Register Configuration, Trim/Calibration, Booter value, Development Mode Disable and Uart STX timeout. In order to delete a command, the user has to select the number of the command for deletion and press the Delete button. The CS is validated when the Manage Configuration Script dialog opens and when the OK button is pressed. Individual commands are validated before being added to the CS commands’ table. Validation errors are shown on the top of the window. User can disable validations when the OK button is pressed, by selecting the Ignore Configuration Script validation errors checkbox. Below individual command types are presented:

  1. Start: Indicates a valid CS. It is always added at the beginning of the CS commands’ table and has the value 0xA5A5A5A5.
  2. Stop: Indicates the end of the CS. It is always added at the end of the CS commands’ table and and has the value 0x00000000.
  3. Register Configuration: Consists of two 32-bit words, the first of which contains the address of an existing register and the second contains the data value of the register. These are always in pairs. When the user selects to add a Register Configuration command to the CS, a popup presenting the available registers grouped in a tree-like structure, is presented. The user can use the search box to search for specific registers or group of registers that contain the text entered in the search box. The names and the addresses of the available registers for the selected device are read from the registers’ xml file specified in the support pack.
../_images/csRegisterConf.png

Figure 45 Register Configuration in CS

  1. Trim/Calibration: Consists of one 32-bit word which is equal to 0x9000YYXX and indicates that the following word(s) are not to be stored to registers but will be used by the SDK SW and YY words which represent the value of the command. XX indicates the TCS group of the command. In order to add a Trim/Callibration command, the user has to first specify the number of the words (YY) and the TCS group (XX). When the number of the words is specified, one row per word is added to the table where the user can fill up the value of each word.
../_images/csTrimCalib.png

Figure 46 Trim/Callibration values in CS

  1. Booter value: Consists of one 32-bit word which is equal to 0x6XXXXXXX indicating this is a value pointing to the Flash product header in flash at address 0xXXXXXXX.
../_images/csBooterVal.png

Figure 47 Booter value in CS

  1. Development Mode Disable: Consists of one 32-bit word which is equal to 0x70000000, disabling the development mode. Development Mode is enabled by default at the initialization phase of the booter. The user’s confirmation is required in order to add the disable development mode command to the CS.
../_images/csDevelDisable.png

Figure 48 Disabling development mode in CS

  1. Uart STX timeout: Consists of One 32 bit word which is equal to 0x8XXXXXXX. The XXXXXXX is used to program the selected STX timeout in multiples of 100uS. So i.e. 0x80000040 is 40x100uS = 4mS.
../_images/csStxTimeout.png

Figure 49 Specifying Uart STX timeout in CS

12.2.2. OTP Header Actions

The following actions are available:

Connect: The user has to establish the connection with the Development Kit if no previous connection has been established via the ‘OTP Image’ tool. Until the connection is established the ‘Read from memory’ and ‘Burn’ buttons are disabled.

Read from memory: After successfully downloading the firmware file to the chip, the user can press the ‘Read from memory’ button to read the current contents of the header in the memory.

Burn: The user can press the ‘Burn’ button to burn the OTP header with the current contents of the header table. Before performing the burn action, a set of validation tests is executed in order to ensure the correctness of each header field. The following image is an example of the messages printed to the log during the header validation tests.

../_images/otp_header_580_log.png

Figure 50 DA14580/581/583 Header validation tests

When a validation test fails or the user is about to make an important change to the header contents, a popup dialog notifies the user accordingly. For each dialog, the user has the option to either stop the burning process or ignore it and continue with the validation checks. The following validation tests are currently performed for DA14580/581/583 OTP Header:

  1. Last burn validation: The existence of ‘header_log.txt’ file is checked. If found, a message informs the user when the memory was burned for the last time.
  2. DMA length validation: ‘DMA length’ value should always be smaller than 32768 bytes. It is automatically set to the maximum-allowed value if it is greater or equal to 32768 bytes and the user ignores the DMA length check popup dialog. Moreover, if a file has been loaded on OTP Image, it is checked that the DMA length is higher than the number of data bytes in that file.
  3. Remapping flag selection: Displays an informative message if the ‘remapping flag’ value has changed to 0.
  4. Customer Code Signature validation: If the ‘signature algorithm’ field has been set and a file has been selected for downloading to the OTP Image, it calculates a hash of the image file code. The calculated value should match to the value of the field Customer Code Signature.
  5. Trim values validation: The fields at addresses 0x47f7C to 0x47f90 are validated against the latest trim values provided by Dialog. The latest trim values are included in file ‘trimValues.txt’ located under the ‘resources’ folder of SmartSnippets™ Toolbox workspace. The file also includes a timestamp indicating the last time the trim values were updated. If the value entered by the user at a trim value field does not match the respective trim value at trimValues.txt file, the user is notified accordingly.
  6. Calibration flag validation: The ‘calibration flag’ should be in accordance with the trim values that have been set. The description field of the calibration flag indicates which bit corresponds to which trim value. If a trim value has been set and the corresponding bit of the calibration flag has not been set or vice versa, the user will be notified accordingly.
  7. 32KHz source selection: Displays a message informing the user about the selected 32KHz source.
  8. Package selection: Displays a message informing the user about the selected package.
  9. Header written already validation: Before performing the actual burn action, SmartSnippets™ Toolbox checks if the memory segment the user is attempting to burn already contains data and notifies the user accordingly; it is up to the user to decide whether to proceed with the burning or not.

After a burn action, a read action is automatically performed in order to refresh the memory contents with the new data. Also, the entire OTP Header section is appended (together with a timestamp) to ‘header_log.txt’ file located under the settings file working directory for future reference.

Export Header to file: Used for exporting the header as a binary (.bin) file or as a file format that is very similar to the Intel hex (.hex) one.

Import Header from file: Used for selecting a file in binary (.bin) format or in SmartSnippets™ Toolbox’ Intel-like format (.hex), containing the OTP header, and importing it into the header table for editing and burning. The imported header file is advised to be a file that has been generated with the export header to file button of the OTP header. When importing a file in OTP header, it is validated that the file contains the expected number of parameters (22 for DA14580/581/583 chips) and that each parameter has the correct length, as it is indicated by the second column of the header table. If the validation tests fail, the file cannot be imported in OTP header, since it is risky to import a file containing wrong header data and burn it in OTP header.

In case of ‘Protected’ fields when importing from file or read from memory, the value is checked with its reverse value. If no match is found a warning message appears on log window.

12.3. OTP NVDS

Note

This tool applies to DA14580/581/583 chip family.

The functionality of OTP NVDS tool is very similar to the functionality of the OTP Header and allows the user to read and write the NVDS memory block. By editing the offset text field, the user can change the address at which a burn and a read operation will be performed. The offset (in bytes) must be a hex number between 0x0000 and 0x8000. For burn operations, the offset should be such so that the address where the last NVDS data byte will be written is smaller than the address where OTP header starts.

An example of the OTP NVDS tab is shown below:

../_images/otp_nvds_580_read_from_memory.png

Figure 51 OTP NVDS

When the burn button is pressed, it is validated that the length of parameters NVDS_TAG_APP_BLE_ADV_DATA, NVDS_TAG_APP_BLE_SCAN_RESP_DATA and NVDS_TAG_DEVICE_NAME is equal to the value indicated by parameters ADV_DATA_TAG_LEN, SCAN_RESP_DATA_TAG_LEN and DEVICE_NAME_TAG_LEN respectively. The user is notified if the validation test fails, and has the option to proceed with the burn action or cancel it. Similar to OTP Header, there are integer-type and string-type fields. For OTP NVDS, the following fields are treated as strings:

  • NVDS_TAG_APP_BLE_ADV_DATA
  • NVDS_TAG_APP_BLE_SCAN_RESP_DATA
  • NVDS_TAG_DEVICE_NAME
  • NVDS_TAG_BD_ADDRESS