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

Save data across WDT reset...

Anthony Verbeck
Prodigy 100 points
Other Parts Discussed in Thread: CC2640

Dear TI,

First the basics:

  1. Processor: CC2640
  2. TI Code Composer Studio 6.1.2.00015
  3. TIRTOS Simplelink 2_13_00_06
  4. xdctools 3_30_03_47
  5. ble_cc26xx_2_01_01_44627
  6. Custom Board: charges via USB, but primarily operates off battery

I need to start by saying I'm not sure exactly where I should post this question as it involves several different modules: ti-arm compiler, BIM, BLE stack, and possibly TI-RTOS so apologies if it's not in the correct forum.

Description:

I am working on a custom board that occasionally gets wedged. We have a different team working on why that is happening. My job has been to get it to reboot and begin processing again. And -- wait for it -- keep the data that was collected before the crash. Fortunately the data is really small, about 256 bytes. We have a FLASH on board that is used to store the data but we really want to keep the Flash accesses to page writes for a lot of reasons the main one being power consumption.

I was able to get the watchdog timer working based on posts in the E2E forums. This worked out great.

Now on to the second part of my challenge. Save the data across a watchdog timer reset. Here's my current idea:

  • Adjust the linker script so that 512 bytes is "removed". Since the CC2640 has 0x5000 (20kb), set the memory size to be 0x4e00 or 512 bytes less.
  • Declare a hard pointer to access this "invisible RAM".
  • In addition to the data itself, I would add a CRC-32 and a structure to manage the data block.

Seems simple enough. Here's what happened: There are three linker scripts: one for the BIM, one for the stack and one for the application. I looked at all three of them and discovered that none were using the top 512 bytes of RAM. So, as an experiment, I attempted part 2 of my plan: I declared a pointer to the "invisible RAM" and incremented the value. What I found was that one of the three executables was clearing that space, presumably the entire RAM. After reviewing my results, I decided it was time to post the following questions:

  1. Does the CC2640 core or boot ROM clear the entire RAM at reset?
  2. I am using TI-RTOS. Are there issues that may involve the RTOS?
  3. If I modify RAM_SIZE in all three projects from 0x5000 to 0x4e00 will the TI generated firmware "ignore" the top 512 bytes?
  4. Is there an easier way to do this? I know this isn't too common, but there are cases where it would be useful.

Thanks for your time and support,

ACV

  • 0
    TI__Guru** 105180 points
    Hello Anthony,

    There is no guaranteed method to preserve RAM across a WDT / system reset, although you may observe that some of the content does persist due to the nature of SRAM. Again, this is not guaranteed as is not in the design specification to retain RAM content across resets. The bootloader doesn't clear RAM contents but some pre-main initialization may clear SECTIONS of RAM, such as .bss. Also, the top section of RAM (near 0x5000) is reserved for the protocol stack ROM. So, using this RAM may yield issues when using the protocol stack - unless you know the stack is not running.

    I would suggest defining a RAM section in the linker command file, under SECTIONS:
    .mymem : > SRAM (HIGH) type = NOINIT
    .stack : > SRAM (HIGH)

    .mymem is shown.

    In your code, add bufferA:
    #pragma DATA_SECTION (bufferA, ".mymem")
    #pragma RETAIN(bufferA)
    volatile static char bufferA[512];

    As always, refer to the TI Compiler (SPNU151) and Assembly tools (SPNU118) manuals.

    Best wishes
  • 0 in reply to JXS
    Prodigy 100 points
    JXS,

    Thanks for the quick reply! This is exactly what I needed to know.

    Thanks,

    ACV
  • 0 in reply to Anthony Verbeck
    Prodigy 100 points
    Just as a final update to this. This works perfectly. I know it's not supported.

    I use a CRC32 on the block of RAM in question. When the CRC fails, everything is set to 0. If it passes, then nothing is touched. We are able to save our data across resets. Sweet.

    Thanks again,

    ACV