User Guide
Setup and Usage Instructions
Introduction
The DevWareX Register Overwrite Warning feature is used to identify when trim and other critical registers are overwritten when they shouldn’t be.
These overwrites occur after the original INI / Shared Settings Modes have been verified, generated either internally by AE/FAE or by customers in the field.
Critical register information can be defined via a .txt file, or within RegDB2 and the resulting SDAT file.
Within RegDB2 is the preferred method, and is currently the only method in use.
Determining Registers to Protect from Overwrite
The critical registers are specified on a per-sensor-revision basis. Each time one of these critical register is changed within DevWareX, the new value is compared to either the value stored in OTPM or a per-defined value. An optional mask can be applied, as well as a “warning only” indicator for when an overwrite is suspicious but allowable in certain situations.
Once the register set is determined, the process of deciding the specific Overwrite combinations is as follows:
The type of register check is either from OTPM, or from the supplied value.
OTPM; the default value is stored in OTPM because either the Si default is incorrect or the value is unique to each Si. No writes of this type are allowed.
RegDB2: “Overwrite Check”.Supplied; the default value is correct in the Si.
RegDB2: “Overwrite Check” and “Check Value”.
Supply a bit-field mask to isolate specific bits, if necessary. Otherwise the entire register is checked.
Use RegDB2 “Check Bitmask” field for this method for either OTPM or Supplied.
Notes:
Ensure that the “Check Value” fits “Check Bitmask”.
“Check Value” is the full value, no shifting required to fit the “Check Bitmask”.Choose either Error or Warning as the result of a mismatch.
Error; the value should never be changed.
Warning; the value may be changed in certain circumstances, and must be discussed with onsemi support personnel.
Shared Settings Development
The Shared Settings User Guide has detailed information on its entire process.
Note that during the initial bring-up of a new sensor, the Overwrite Registers may have been entered in to RegDB2 (and thus in the SDAT file) but OTPM has not yet been programmed. This will cause unintended Overwrite error reporting. There are several methods of accounting for this.
Disable Overwrite Checking
In the early stages of settings development it is best to disable overwrite checking when RegDB2 has been updated for overwrite protection. The following Python code can be added to the sensor’s src\devware\customize.ini file by placing them in the file’s stand-alone “Python:” preset which is run when the INI file is loaded or reloaded.
For one register, example:
reg.DAC_LD_34_35.overwrite_check = 0
For all registers:
for r in reg:
r.overwrite_check = 0
Manual Update of OTPM-based Registers
There will be a period of development when the OTPM-based overwrite registers have been identified but have not yet been added to OTPM. When the OTPM-based registers that need overwrite protection have been entered in to RegDB2, a function should be created that checks for these registers' presence in OTPM and set them if not found These same register settings must be removed from the base Shared Settings as they are now accounted for in this new function. The function should be called with the Reset function as that is called to initialize a Mode. Only available for ApBase, so place in src\devware\customize.ini
[OTPM_Init]
regs=[[
[0x30c6, 1],
[0x30c8, 2],
[0x30ca, 3]]
for rows in regs:
if rows[0] not in apbase.Camera().sensor.otpm_registers_by_address:
reg.reg(rows[0]).value=rows[1]
This can be removed once the OTPM has been initialized.
DevWareX Menu Dialog
A new DevWareX Menu item is color-coded to indicate the current warning level:
Green; no overwrites detected.
Yellow; warning overwrites detected.
Red; unallowed overwrites detected.
The Menu item is located next to the “Register” icon and looks like this:
Register Check File format
The .txt file name has the format of <sensor>-<revision>-OTPM.txt, and is located in the DevWareX SDAT folder, “sensor_data”.
This method can be used for initial checking of values/masks during bring-up, and once verified the data is to be placed in to RegDB2.
Each line of text is for an individual register. <address> is required, and all other items optional and can be used in any combination. The format is:
<address> [, <bit-field mask>] [, value=<value>] [, warning_only]
<address>; register address in hex.
[, <bit-field mask>]; optional mask to be applied to check value.
[, value=<value>] ; optional value to compare register to instead of OTPM value.
[, warning_only]; optional indicator to warn-only about a value mismatch - some modes can have different values.
Note: a value of 0xFFFF for <address> indicates an uninitialized file and serves as a warning to apply real values to the text file.
SDAT File format
See the RegDB2 User Guide for information on how to enter this information and how it is represented in the exported SDAT file.
DevWareX Usage
Each time one of these critical register is changed within DevWareX, either through the running of a Preset or the Register dialog, the new value is compared to the expected one.
The color of the following Menu icon will change to Yellow or Red when a violation is detected.
Click the icon to open the Warning dialog. The icons on the left indicate the register status.
overwrite checking enable; no overwrite detected.
overwrite checking enable; unallowed overwrite detected.
overwrite checking enable; possible improper overwrite detected.
OTPM-programmed value not enabled for overwrite warnings (not in .txt file).
The following is an example of the dialog:
The
displays the status as described in the Overview section; in this example, it shows an unallowed overwrite has been detected.
The table displays shows the registers defined in the “Register Check” .txt file, along with the status icon and the various columns as they relate to the .txt file:
Address; register address from <address>.
Mask; from <bit-field mask> if defined in .txt file, otherwise from the SDAT file.
OTPM; value read from OTPM, or “n/a” if “value=<value>” used in .txt file.
Check; value from “value=<value>” used in .txt file, or “n/a” if not.
Current; current value read from register.
Comment; status description.
The “Overwrite results only” shows only the registers defined in the .txt file. If you unselect that, you’ll see
for all registers set in OTPM but not in the .txt file.
“Save..” will save the current table display to a .csv file.
“Refresh Table” will recheck for unallowed overwrites, but in most cases these are detected automatically.
The Appendix shows the contents of the .txt file used to generate the above example.
DevWareX Preset Warnings
Every time a Preset is run, the registers defined in the .txt file are compared for overwrites. If an unallowed or possible unallowed overwrite is detected a warning dialog appears:
The Preset should be inspected as to why that value is being flagged as error or warning.
These Warnings can be disabled by selecting the check-box of “Don’t show this message in a pop-up again.”.
It can be re-enabled via “Options / Warning Dialogs / Reset All”.
Script to Check for Register and Bit-field Overwrites
Use the DevWareX Command-Line Utility “field_wr” with option “-overwrite” to check a DevWareX Log for register overwrites. Usually meant for INI files from customers as Shared Settings does this check during the compile stage.
The INI file must be in REG= / BITFIELD= format. Select “Enable Log”, select “Hex” for the register format.
Run the preset. When completed, select “Save to Ini…” to capture the results.
Note that any bit-field writes in the settings (read/modify/write) are not captured as such in the converted INI file, but instead as a register write (“REG=”). This is not an issue as “field_wr” will be using the Overwrite fields from the SDAT file, specifically “Check Bitmask” and “Check Value”. Note that Writes to OTPM Check Types are never allowed as these are loaded from OTPM.
Usage instructions for “field_wr” are found here.
Appendix
The contents of the .txt file used to generate the above example.
Add Comment