With the NHS3100 SDK Temperature Logger, how can we restore a devkit tag EEPROM to a configurable state after it is set to no-more-config?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

With the NHS3100 SDK Temperature Logger, how can we restore a devkit tag EEPROM to a configurable state after it is set to no-more-config?

Jump to solution
1,076 Views
stevewald
Contributor III

We inadvertently set some tags to the configuration locked state using our propietary App. Can we use Flash Magic or a simple bit of firmware to restore the configuration to unlocked? How do we find our way around the EEPROM in Flash Magic with respect to the SDK writes and reads?

For example... am I even in the correct section here? Or is this RAM I am looking at? The user's manual puts RAM at address 1xxx xxxx and EEPROM at 3xxx xxxx, but F-M ISP>Display Memory shows nothing at the latter.

10000000 0046000000FFFFFF3600000000000000 .F......6.......
10000010 00000000000000000000000049000000 ............I...
10000020 AABEAABE50000000D90900005A000000 ....P.......Z...
10000030 000000002000314E0000000000000000 .... .1N........
10000040 000000006E00FFFF0B01000001000000 ....n...........
10000050 45240000020000000524000009000000 E$.......$......
10000060 E92300000A000000C1230000FFFFFFFF .#.......#......
10000070 00000000000000000100000000000000 ................

Steve

Labels (1)
0 Kudos
1 Solution
1,016 Views
stevewald
Contributor III

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.

View solution in original post

0 Kudos
2 Replies
1,016 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Steve,

Would you please specify how you set the tags to configuration lock state? Did you set this bit as below?

pastedImage_1.png

Please kindly clarify.

Thanks for your patience!

Have a great day,
Kan


-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
1,017 Views
stevewald
Contributor III

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.

0 Kudos