• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 51 subscribers
  • Views 690 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.

Original question:

RTOS/CC2640R2F: Can power loss create data corruption, how to avoid?

RTOS/CC2640R2F: Could a corrupted NVM cause system not to boot?

Glenn Vassallo
Guru 21435 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: UNIFLASH, SYSBIOS

Tool/software: TI-RTOS

We are investigating the possibility that corruption of the NVM due to a brownout is causing the system to not boot successfully.

We have a number of devices that are failing to boot, and the failure occurs well before we read the NVM. We can get these devices to function again by erasing and reprogramming.

Questions:

  1. Is NVM initialised, read or checked during the boot sequence?

  2. If the NVM is corrupted, could this cause the system not to boot before main or during Icall_init? If yes, what could be happening to cause the failure to boot?

  • 0
    TI__Guru**** 317180 points
    - Are you able to read the flash on the failing devices? The reason I ask is that could show what has changed in the flash compared to a functional chip.
    - I assume that your program works as intended if you use a stable supply?
    - Do you know that you have received a brownout?
  • 0 in reply to TER
    TI__Guru**** 317180 points
    Closing this thread since I haven't heard back from you.
  • 0 in reply to TER
    Guru 21435 points

    We don't believe the flash could be read, the developer has tried using Uniflash or SmartRF Flash Programmer 2.

    However, running a “Verify” in SmartRF Flash Programmer 2 results in the below output:
    (note that 0x0001E000 is the start of the “user” parts of the SNV, so this is where data gets written by osal_snv_write())

     

    Does this output shed any light on things?

    >Initiate access to target: XDS-L3003534.

    >Reading file: C:/Users/drbie/Desktop/smrtshep_observer_cc2640r2lp_app.hex.

    >Start flash verify ...

    >Page: 0 verified OK.

    >Page: 1 verified OK.

    >Page: 2 verified OK.

    >Page: 3 verified OK.

    >Page: 4 verified OK.

    >Page: 5 verified OK.

    >Page: 6 verified OK.

    >Page: 7 verified OK.

    >Page: 8 verified OK.

    >Page: 9 verified OK.

    >Page: 10 verified OK.

    >Page: 11 verified OK.

    >Page: 12 verified OK.

    >Page: 13 verified OK.

    >Page: 14 verified OK.

    >Page: 15 verified OK.

    >Page: 16 verified OK.

    >Skip verification of unassigned page: 17.

    >Skip verification of unassigned page: 18.

    >Skip verification of unassigned page: 19.

    >Skip verification of unassigned page: 20.

    >Skip verification of unassigned page: 21.

    >Skip verification of unassigned page: 22.

    >Skip verification of unassigned page: 23.

    >Skip verification of unassigned page: 24.

    >Skip verification of unassigned page: 25.

    >Skip verification of unassigned page: 26.

    >Skip verification of unassigned page: 27.

    >Skip verification of unassigned page: 28.

    >Skip verification of unassigned page: 29.

    >Verification failed at address 0x0001E000 (in page 30). Expected 0xFF, read 0x00.

    >Reset target ...

    >Reset of target successfull.

  • 0 in reply to Glenn Vassallo
    TI__Guru**** 317180 points
    You wrote that you have a number of devices that fails to boot. Why do you suspect a brownout when booting?
  • 0 in reply to TER
    Guru 21435 points
    We are not suspecting a brownout when booting. We were investigating whether a brownout during the write process to the NVM, could then cause corruption, which then potentially leads to the devices not booting up.

    This post references previous posts, which explain the original issue we are trying to troubleshoot. But effectively, we have a certain percentage (on average around 5%) of devices that are not booting up after they are used in the field. An erase and reflash of the firmware get the devices working again.
  • 0 in reply to Glenn Vassallo
    Guru 21435 points

    This came out of the ROV when the test device throws a HWI when booting:

    Does this shed any additional light on the problem?

     

    Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0x2afe8

    $addr

    N/A

    $type

    ti.sysbios.family.arm.m3.Hwi.ExcContext

    threadType

    Task

    threadHandle

    0x2000214c

    threadStack

    0x2000219c

    threadStackSize

    1000

    r0

    0x200001

    r1

    0x4014

    r2

    0x4013

    r3

    0x200001

    r4

    0x11000000

    r5

    0x2afe8

    r6

    0x4013

    r7

    0x0

    r8

    0x1e

    r9

    0x1e000

    r10

    0x20000bd0

    r11

    0x1

    r12

    0x0

    sp

    0x200024c0

    lr

    0xeff7

    pc

    0xd654

    psr

    0x21000200

    ICSR

    0x414803

    MMFSR

    0x0

    BFSR

    0x82

    UFSR

    0x0

    HFSR

    0x40000000

    DFSR

    0x0

    MMAR

    0x2afe8

    BFAR

    0x2afe8

    AFSR

    0x0

    Exception call stack

    0 HalFlashRead at hal_flash_wrapper.c:78 :

    PC=0x0000D654

    1 halAssertHazardLights at :0 :

    PC=0x00000000

  • 0 in reply to Glenn Vassallo
    TI__Guru**** 317180 points
    I asked around some and this thread e2e.ti.com/.../2785745 could be relevant in your case. Do you use the kunde osal_snv APIs and what is the voltage when doing so, ref the E2E post I linked to?
  • 0 in reply to TER
    Guru 21435 points
    Thanks TER, that post is for the same problem, this post linked back to that one.
  • 0 in reply to Glenn Vassallo
    TI__Guru**** 317180 points
    Sorry, forgot that this post was referred to. But I don't think you have answered the rest of my last post?
  • 0 in reply to TER
    Guru 21435 points

    I believe we may have worked out the issue, the low power protection for NVM needed to be switched on. This is being tested, we can close this one off for now.