• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 56 subscribers
  • Views 711 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652R: NV Memory gets corrupted

Mario Braun
Intellectual 435 points
Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK

Hi everyone!

I found a weird issue with the NV Memory. Some of our light stop working after a while. It took me a week to recreate this issue in our test room.

At the moment I am not sure why this is happening, but I know the result.
It also seems that it only happens at network creation (Centralized Only). If all is set up, the issue will not appear.

I debugged some of the lights (with this issue).
It looks like many NV items have the length 0 and the complete NV memory is full.

The issue came up with SDK version 3.30, but I could also recreate it with SDK version 3.40

I will try to find out why this is happening (I think it has something to do with a failured/timed-out TCLK exchange).

Has someone had a similar issue?

BR Mario

  • 0
    TI__Mastermind 35070 points

    Hi,

    If the issue is related to network creation, can you try joining the devices at a longer random interval? For example, each device attempts to join at a random interval between 1 second and 1 minute.

    Can you provide a sniffer log?
    Evidence of TCLK timeout would occur pretty quickly (BDBC_TC_LINK_KEY_EXANGE_TIMEOUT ms).

    Regards,
    Toby

  • 0
    TI__Guru**** 218777 points

    Hi Mario,

    Please provide the values of NWK_MAX_DEVICE_LIST and ZDSECMGR_TC_DEVICE_MAX along with any other changes to the default stack configuration.  http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#non-volatile-memory-items 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 435 points

    Thanks for the inputs, but I think I found the issue.

    There is a problem with NVOCMP_findSignature function in NVOCMP_compact.

    I will try to explain it by a example:

    The first header of NV Items was broken.
    Compressed Header: 0x00 0x40 0x00 0x05 0x00 0x00 0x00 --> Last Byte should be Signature 0x96; item gets marked invalid
    Offset of next signature is found.
    Next Compressed Header: 0x01 0x04 0x00 0x15 0x40 0x06 0xD6 --> Also wrong because its shifed by 1 byte (Sign 0x96 comes after 0xD6)

    My BugFix looks like this (Line 3737 in nvocmp.c):

    // Detected a problem, find next header (scan for signature)
NVOCMP_ALERT(FALSE, "Attempting to find signature...")
bool foundSig = NVOCMP_findSignature(srcPg, &srcOff);
srcOff++; //MBMB BugFix We don't need SignatureOffset; we need HeaderOffset

    Can you please verify this?

    BR Mario

  • 0 in reply to Mario Braun
    TI__Mastermind 35070 points

    I see what you mean.

    It seems that when NVOCMP_findSignature finds a signature (eg 0x96) at byte index (i - 1), it increments srcOff by (i - 1), so srcOff now points to the signature byte.
    Then NVOCMP_compactPage aligns srcOff to the start of item header (srcOff -= NVOCMP_ITEMHDRLEN), so that srcOff now points to the byte just before the item header, in order to parse it.

    Your solution of then incrementing srcOff by 1 would make sure that srcOff points the first byte of the item header.

    Assuming that srcOff is intended to point to the first item header at the start of the loop in NVOCMP_compact, then I believe your workaround should work.
    Let me confirm this with the driver's developers.

    In parallel, can you do the following:
    - provide the numbers that Ryan as asked for (NWK_MAX_DEVICE_LIST, ZDSECMGR_TC_DEVICE_MAX)
    - provide any modifications to NV region (see http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#modifying-non-volatile-memory-allocation)
    - confirm that you enter NVOCMP_compact by debugging

  • 0 in reply to Toby
    Intellectual 435 points

    I haven't changed anything in this defines:

    NWK_MAX_DEVICE_LIST = 20
    ZDSECMGR_TC_DEVICE_MAX = 40

    The NV Regions are the same as in OTA Client example.

    #define FLASH_BASE              0x00000000
    #define FLASH_NV_BASE           0x52000
    #define FLASH_NV_SIZE           0x4000

    Yes, I can confirm that NVOCMP_compact is entered at debugging.

    My configuration was like this:

    Breakpoint at Line 2560 --> After reading uncompressed header
    Breakpoint at Line 3697 --> After decompressing header
    Breakpoint at Line 3738 --> After NVOCMP_findSignature (to look up data in memory browser)

    Before I started the program, I loaded the corrupted NV region in the memory (I have it as a HEX-File if you need it for simple recreation)

    BR Mario

  • 0 in reply to Mario Braun
    Intellectual 435 points

    Sorry, ZDSECMGR_TC_DEVICE_MAX = 3, because my devices are routers.

    The value for the ZC is unknown, because it's from another vendor.

    BR Mario

  • 0 in reply to Mario Braun
    TI__Mastermind 35070 points

    The development team has found and fixed this issue: change was made so that NVOCMP_findSignature now increments srcOff by i (instead of i-1).
    In the context of NVOCMP_compact, this is equivalent to your workaround, however it may be better to apply the fix in NVOCMP_findSignature (in case other functions were to call it).

    The fix will be applied in the next quarterly SDK release.

  • 0 in reply to Toby
    Intellectual 435 points

    Hi.

    This was also my first approach, but since the function is called findSignature I thought it would be better if the index is pointing to the signature.

    @Ryan: Please add this fix in you known issues post.

    Hugh Thanks to Toby, Ryan and the dev team!

    Have a nice weekend!
    BR Mario

  • 0 in reply to Mario Braun
    TI__Guru**** 218777 points

    Hi BR Mario,

    I have added this bug to the Known Issues E2E sticky post, thank you for the excellent debugging and diligence towards helping create a better Z-Stack solution.

    Regards,
    Ryan