• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 299 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TI-15.4-STACK-GATEWAY-LINUX-SDK: Parse nv-simulation.bin file error after host reboot sometimes.

user4650693
Intellectual 440 points

Part Number: TI-15.4-STACK-GATEWAY-LINUX-SDK

I use Linux SDK 4_30_00_06 still see parse nv-simulation.bin file after host reboot sometimes. Previous SDK 4_20_00_05 sometimes will see this error too.

It seems run into NVOCMP_RECOVER_COMPACT or NVOCMP_RECOVER_ERASE during initNV stage after reboot when I compare with the buggy nv-simulation.bin file.

This reset error induces host loss network info and device list info absolutely although MAC layer (CoP) work normally. That makes our system abnormal.

Some questions for this issue:

1. What kinds of situations will induce compaction process when all sensors are connected to the PAN and ready to run?

2. Can I speed up to generate compaction process? For example, reduce the value of PAGE_SIZE_LSHIFT from default 13 to smaller one (e.g. 6).

3. I found device frame counter update (over FRAME_COUNTER_SAVE_WINDOW=25) will induce nv-simulation.bin write operation. Will it induce compaction task if the PAN is running for a long time?

4. It seems update device data (like frame counter) does not update on the same location in nv-simulation.bin file, but invalidate old one and create new one. Will system re-use the invalid old one later on?

Regards,

Peter.

  • 0
    TI__Genius 14845 points

    Hi, 

    Thanks for your question. 

    What do you mean by "see parse nv-simulation.bin file after host reboot"? The nv-simulation file has to be deleted if you want clean the information about previous connection. Remember that this has to be done on the sensor side too. 

    Which device are you using? Can you share some details on the use-case?

    Thanks, 
    Elin 

  • 0 in reply to Elin W
    Intellectual 440 points

    Hi Elin,

    This statement "see parse nv-simulation.bin file after host reboot sometimes" is typo. I mean "see parse nv-simulation.bin file ERROR after host reboot sometimes".

    Our GW's CoP uses CC1312 SoC. Our device is H/T sensor and uses CC1312 SoC too.

    It is hard to re-produce this issue, so I can not write down a precise test steps.

    The use case might be: (1) Setup a PAN with multiple H/T sensors. Make sure all sensors are connected. (2) Make sure all sensors will report H/T data periodically (e.g. per 5 min). (3) Normally, we will leave this PAN for a while (few days) to collector H/T data to benchmark some performance metrics (e.g. packet success rate).

    The issue come from some cases, like GW power re-cycle (this is a normal test case and can be happen at deployed field). Assume the PAN was connected with 20 devices before power re-cycle, After GW power re-cycle and try to list the device number from host. Sometimes, we will get zero device! In this case, we will see some error log, host parse nv-simulation.bin file ERROR & found nv-simulation.bin was reset.

    The nv-simulation.bin file SHOULD NOT be reset (e.g. when GW power re-cycle) as all sensors info are gone! And we must re-join all sensors again. It is not acceptable.

    BTW, can you answer the question 1,2,3,4? Thanks.

    Peter.

  • 0 in reply to user4650693
    Intellectual 440 points

    Hi Elin,

    Any update from TI? Thanks.

    Peter.

  • 0 in reply to user4650693
    TI__Genius 14845 points

    Hi Peter, 

    Apologies for the delay. 

    Do you still experience this issue? 

    I'll look into your questions and get back to you as soon as I have an update. 

    Thanks, 
    Elin 

  • 0 in reply to Elin W
    Intellectual 440 points

    Hi Elin,

    Frequency is low, and Yes.

    Peter.

  • 0 in reply to user4650693
    Intellectual 440 points

    Hi TI expert,

    I got a chance to snap the nv-simulation.bin file. The GW was run over 12 days.

    This nv-simulation.bin file was backup before GW power recycle purposely, Before GW power recycle, I did list sensor device and found number of device is correct (18 devices) and info is valid. GW was receiving sensor data correctly.

    However, after GW power recycle, the collector parse with error. Error log as below:


    0.212: ERROR: <linux/linux_specific.c> Called in pthread_setname_np().
    TI Collector
    0.295: NVOCMP_ALERT: message=NVOCMP Init. Called!
    0.298: nvram: Loaded: /mnt/data/HEM/db/nv-simulation.bin, length=32768
    0.301: read: pg:0, ofs=0x0000, num=4
    0.301: 00000000: 78 04 00 96 - |x... |
    0.302: read: pg:0, ofs=0x0004, num=4
    0.302: 00000000: ff ff f8 96- | .... |
    0.303: read: pg:0, ofs=0x0008, num=4
    0.304: 00000000: -1f ff 01 96 | .... |
    0.304: read: pg:0, ofs=0x000c, num=4
    0.305: 00000000: - 00 10 01 96 | ....|
    0.305: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.306: write: pg:0, ofs=0x0000, num=4
    0.306: 00000000: ff 01 03 96 - |.... |
    0.308: write: pg:0, ofs=0x0004, num=4
    0.308: 00000000: ff ff ff 96- | .... |
    0.308: write: pg:0, ofs=0x0008, num=4
    0.309: 00000000: -ff ff ff 96 | .... |
    0.309: write: pg:0, ofs=0x000c, num=4
    0.310: 00000000: - ff ff ff 96 | ....|
    0.310: read: pg:0, ofs=0x0000, num=4
    0.311: 00000000: ff 01 03 96 - |.... |
    0.312: read: pg:0, ofs=0x0004, num=4
    0.312: 00000000: ff ff ff 96- | .... |
    0.313: read: pg:0, ofs=0x0008, num=4
    0.313: 00000000: -ff ff ff 96 | .... |
    0.314: read: pg:0, ofs=0x000c, num=4
    0.314: 00000000: - ff ff ff 96 | ....|
    0.320: read: pg:1, ofs=0x0000, num=4
    0.320: 00002000: 78 04 00 96 - |x... |
    0.321: read: pg:1, ofs=0x0004, num=4
    0.321: 00002000: ff ff f8 96- | .... |
    0.322: read: pg:1, ofs=0x0008, num=4
    0.322: 00002000: -20 00 02 96 | ... |
    0.329: read: pg:1, ofs=0x000c, num=4
    0.329: 00002000: - 00 10 02 96 | ....|
    0.330: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.330: write: pg:1, ofs=0x0000, num=4
    0.331: 00002000: ff 01 03 96 - |.... |
    0.332: write: pg:1, ofs=0x0004, num=4
    0.332: 00002000: ff ff ff 96- | .... |
    0.333: write: pg:1, ofs=0x0008, num=4
    0.333: 00002000: -ff ff ff 96 | .... |
    0.334: write: pg:1, ofs=0x000c, num=4
    0.339: 00002000: - ff ff ff 96 | ....|
    0.340: read: pg:1, ofs=0x0000, num=4
    0.340: 00002000: ff 01 03 96 - |.... |
    0.340: read: pg:1, ofs=0x0004, num=4
    0.341: 00002000: ff ff ff 96- | .... |
    0.341: read: pg:1, ofs=0x0008, num=4
    0.342: 00002000: -ff ff ff 96 | .... |
    0.342: read: pg:1, ofs=0x000c, num=4
    0.347: 00002000: - ff ff ff 96 | ....|
    0.348: read: pg:2, ofs=0x0000, num=4
    0.348: 00004000: 7c 04 00 96 - ||... |
    0.349: read: pg:2, ofs=0x0004, num=4
    0.349: 00004000: ff ff fc 96- | .... |
    0.350: read: pg:2, ofs=0x0008, num=4
    0.350: 00004000: -1f ea 03 96 | .... |
    0.354: read: pg:2, ofs=0x000c, num=4
    0.355: 00004000: - 00 10 03 96 | ....|
    0.356: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.356: write: pg:2, ofs=0x0000, num=4
    0.357: 00004000: ff 01 03 96 - |.... |
    0.358: write: pg:2, ofs=0x0004, num=4
    0.358: 00004000: ff ff ff 96- | .... |
    0.367: write: pg:2, ofs=0x0008, num=4
    0.368: 00004000: -ff ff ff 96 | .... |
    0.373: write: pg:2, ofs=0x000c, num=4
    0.373: 00004000: - ff ff ff 96 | ....|
    0.374: read: pg:2, ofs=0x0000, num=4
    0.374: 00004000: ff 01 03 96 - |.... |
    0.376: read: pg:2, ofs=0x0004, num=4
    0.376: 00004000: ff ff ff 96- | .... |
    0.377: read: pg:2, ofs=0x0008, num=4
    0.377: 00004000: -ff ff ff 96 | .... |
    0.378: read: pg:2, ofs=0x000c, num=4
    0.378: 00004000: - ff ff ff 96 | ....|
    0.395: read: pg:3, ofs=0x0000, num=4
    0.395: 00006000: fe 04 03 96 - |.... |
    Nwk: Started
    0.396: 00006000: ff ff ff 96- | .... |
    0.397: read: pg:3, ofs=0x0008, num=4
    0.397: 00006000: -ff ff ff 96 | .... |
    0.398: read: pg:3, ofs=0x000c, num=4
    0.398: 00006000: - ff ff ff 96 | ....|
    Info: Channel 90

    BTW, can I attach this nv-simulation.bin for your reference? Do  you have any feedback for my question 1,2,3,4?

    Regards,

    Peter.

  • 0 in reply to Elin W
    Intellectual 440 points

    I got a chance to save nv-simulation.bin file before GW power recycle. After GW power cycle, collector parse nv-simulation.bin file error and reset it again (sensor data gone).
    Before GW power recycle, it was running over 12 days. And I checked with 18 sensors info is fine. And GW received sensor data normally.
    I try to power recycle GW purposely after 12 days as I think collector might have page full cases and do compactation operations on nv-simulation.bin file several times.
    This time as I suspect, after GW power recycle, collector parse nv-simulation.bin file with error and reset it. The error log as below:

    0.049: ERROR: <linux/linux_specific.c> Called in pthread_setname_np().
    TI Collector
    0.127: NVOCMP_ALERT: message=NVOCMP Init. Called!
    0.128: nvram: Loaded: /mnt/data/HEM/db/nv-simulation.bin, length=32768
    0.129: read: pg:0, ofs=0x0000, num=4
    0.130: 00000000: 78 04 00 96 - |x... |
    0.131: read: pg:0, ofs=0x0004, num=4
    0.132: 00000000: ff ff f8 96- | .... |
    0.132: read: pg:0, ofs=0x0008, num=4
    0.132: 00000000: -1f ff 01 96 | .... |
    0.133: read: pg:0, ofs=0x000c, num=4
    0.134: 00000000: - 00 10 01 96 | ....|
    0.140: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.140: write: pg:0, ofs=0x0000, num=4
    0.141: 00000000: ff 01 03 96 - |.... |
    0.141: write: pg:0, ofs=0x0004, num=4
    0.142: 00000000: ff ff ff 96- | .... |
    0.142: write: pg:0, ofs=0x0008, num=4
    0.144: 00000000: -ff ff ff 96 | .... |
    0.144: write: pg:0, ofs=0x000c, num=4
    0.145: 00000000: - ff ff ff 96 | ....|
    0.145: read: pg:0, ofs=0x0000, num=4
    0.146: 00000000: ff 01 03 96 - |.... |
    0.146: read: pg:0, ofs=0x0004, num=4
    0.147: 00000000: ff ff ff 96- | .... |
    0.148: read: pg:0, ofs=0x0008, num=4
    0.148: 00000000: -ff ff ff 96 | .... |
    0.149: read: pg:0, ofs=0x000c, num=4
    0.149: 00000000: - ff ff ff 96 | ....|
    0.150: read: pg:1, ofs=0x0000, num=4
    0.150: 00002000: 78 04 00 96 - |x... |
    0.151: read: pg:1, ofs=0x0004, num=4
    0.152: 00002000: ff ff f8 96- | .... |
    0.152: read: pg:1, ofs=0x0008, num=4
    0.153: 00002000: -20 00 02 96 | ... |
    0.153: read: pg:1, ofs=0x000c, num=4
    0.154: 00002000: - 00 10 02 96 | ....|
    0.154: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.155: write: pg:1, ofs=0x0000, num=4
    0.156: 00002000: ff 01 03 96 - |.... |
    0.156: write: pg:1, ofs=0x0004, num=4
    0.157: 00002000: ff ff ff 96- | .... |
    0.157: write: pg:1, ofs=0x0008, num=4
    0.158: 00002000: -ff ff ff 96 | .... |
    0.158: write: pg:1, ofs=0x000c, num=4
    0.159: 00002000: - ff ff ff 96 | ....|
    0.160: read: pg:1, ofs=0x0000, num=4
    0.160: 00002000: ff 01 03 96 - |.... |
    0.161: read: pg:1, ofs=0x0004, num=4
    0.161: 00002000: ff ff ff 96- | .... |
    0.162: read: pg:1, ofs=0x0008, num=4
    0.162: 00002000: -ff ff ff 96 | .... |
    0.163: read: pg:1, ofs=0x000c, num=4
    0.164: 00002000: - ff ff ff 96 | ....|
    0.164: read: pg:2, ofs=0x0000, num=4
    0.165: 00004000: 7c 04 00 96 - ||... |
    0.165: read: pg:2, ofs=0x0004, num=4
    0.166: 00004000: ff ff fc 96- | .... |
    0.166: read: pg:2, ofs=0x0008, num=4
    0.168: 00004000: -1f ea 03 96 | .... |
    0.168: read: pg:2, ofs=0x000c, num=4
    0.168: 00004000: - 00 10 03 96 | ....|
    0.169: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.170: write: pg:2, ofs=0x0000, num=4
    0.170: 00004000: ff 01 03 96 - |.... |
    0.171: write: pg:2, ofs=0x0004, num=4
    0.172: 00004000: ff ff ff 96- | .... |
    0.172: write: pg:2, ofs=0x0008, num=4
    0.172: 00004000: -ff ff ff 96 | .... |
    0.173: write: pg:2, ofs=0x000c, num=4
    0.173: 00004000: - ff ff ff 96 | ....|
    0.174: read: pg:2, ofs=0x0000, num=4
    0.174: 00004000: ff 01 03 96 - |.... |
    0.176: read: pg:2, ofs=0x0004, num=4
    0.176: 00004000: ff ff ff 96- | .... |
    0.177: read: pg:2, ofs=0x0008, num=4
    0.177: 00004000: -ff ff ff 96 | .... |
    0.177: read: pg:2, ofs=0x000c, num=4
    0.178: 00004000: - ff ff ff 96 | ....|
    0.178: read: pg:3, ofs=0x0000, num=4
    0.179: 00006000: fe 04 03 96 - |.... |
    Nwk: Started
    0.180: 00006000: ff ff ff 96- | .... |
    0.181: read: pg:3, ofs=0x0008, num=4
    0.181: 00006000: -ff ff ff 96 | .... |
    0.182: read: pg:3, ofs=0x000c, num=4
    0.182: 00006000: - ff ff ff 96 | ....|

    Any update for my question 1,2,3,4? Do you need this nv-simulation.bin file for double check?

    Regards,
    Peter.

  • 0 in reply to Elin W
    Intellectual 440 points

    I got a chance to save nv-simulation.bin file before GW power recycle. After GW power cycle, collector parse nv-simulation.bin file error and reset it again (sensor data gone).
    Before GW power recycle, it was running over 12 days. And I checked with 18 sensors info is fine. And GW received sensor data normally.
    I try to power recycle GW purposely after 12 days as I think collector might have page full cases and do compactation operations on nv-simulation.bin file several times.
    This time as I suspect, after GW power recycle, collector parse nv-simulation.bin file with error and reset it. Snipped error log as below:

    0.049: ERROR: <linux/linux_specific.c> Called in pthread_setname_np().
    TI Collector
    0.127: NVOCMP_ALERT: message=NVOCMP Init. Called!
    0.128: nvram: Loaded: /mnt/data/HEM/db/nv-simulation.bin, length=32768
    0.129: read: pg:0, ofs=0x0000, num=4
    0.130: 00000000: 78 04 00 96 - |x... |
    0.131: read: pg:0, ofs=0x0004, num=4
    0.132: 00000000: ff ff f8 96- | .... |
    0.132: read: pg:0, ofs=0x0008, num=4
    0.132: 00000000: -1f ff 01 96 | .... |
    0.133: read: pg:0, ofs=0x000c, num=4
    0.134: 00000000: - 00 10 01 96 | ....|
    0.140: NVOCMP_ALERT: message=Corrupted or Version/Signature mismatch.
    0.140: write: pg:0, ofs=0x0000, num=4
    0.141: 00000000: ff 01 03 96 - |.... |
    0.141: write: pg:0, ofs=0x0004, num=4
    0.142: 00000000: ff ff ff 96- | .... |
    0.142: write: pg:0, ofs=0x0008, num=4
    0.144: 00000000: -ff ff ff 96 | .... |

    Any update for my question 1,2,3,4? Do you need this nv-simulation.bin file for double check?

    Regards,
    Peter.

  • +1 in reply to user4650693
    TI__Genius 14845 points

    Hi Peter, 

    Thanks for the update. 

    Here is some feedback regarding your questions from your original post: 

    1. Compaction is triggered when the device is running out of free space in NV storage. Under regular application usage, it would take many sensors associating to the collector to eventually fill up NV. With the default settings, compaction will not be triggered unless 100s+ sensors are connected to the network however because there is not a lot of data written to NV (~10-30 bytes last time I checked) upon association.
    2. You can reduce the size of the NV to fill up the NV storage region quicker, thereby triggering the compaction process. Either reducing the page size by modifying FLASH_PAGE_SIZE (or modifying PAGE_SIZE_LSHIFT) to a smaller value like 256 bytes, and/or reducing the amount of flash pages used by the application by setting NVOCMP_NVPAGES to 2 (if not currently using 2 pages). I would recommend first calling the 'NVOCMP_compactNvApi' function first however with the 'minAvail' parameter set to zero to force compaction.
    3. Reducing the frame counter value will increase the frequency of writing the frame counter data to NV, so do this if you want to trigger compaction quicker.
    4. No, invalid entries will be removed by the compaction process after NV storage passes the compaction threshold.

    Thanks, 
    Elin