Hi Kan Li,
I’m sorry for the confusion. I thought this locking feature was part of the original SDK t-logger code, but it is one of our local additions.
I will describe these changes because I am not sure exactly what the SDK does to store the locking state – but it goes into ‘memory’ with the rest of the logging configuration status. We believe that ‘memory’ in this case is EEPROM, but would like that confirmed. Our clue is that Memory_Init() and Memory_DeInit() call Chip_EEPROM_* functions with the EEPROM_OFFSET_CONFIG parameter. We do not believe this is related to your reference to Table 164. WSTATE register, bit 31, LOCK_PARWEP.
In msghandle_protocol.h, we create a new APP_MSG_EVENT enumeration for APP_MSG_EVENT_CONFLOCKED. We also add a new word “int16_t configLocked;” to the APP_MSG_CMD_SETCONFIG_S and the APP_MSG_RESPONSE_GETCONFIG_S.
In the memory.c function Memory_AddToState(events), we have added APP_MSG_EVENT_CONFLOCKED to the list of events which sets sAlon.uninterrupted to true. In this function, we also see that the CONFLOCKED state will be added to sConfig.status as part of a new configuration event.
We would like to maintain some administrative control over unlocking the configuration of our tags (e.g. in test), while having just the locking capability in place for our customers – perhaps by some separate app or fw only available to admin. We would also like some visibility into the EEPROM and our logging status stored there, especially for forensic analysis of logging results when the tags fail or stop under extremes of voltage and temperature.
New Edit:
It appears that we do have visibility into the EEPROM using a uTrust tag reader. With a better understanding of our own programming as detailed above, we have been able to access the lock state and sole the problem.
Thanks for your help.
