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.

RAM Data retention TM4C1294

Hello,

I am using an application in which notable amount of sensitive data is resident on RAM. In case of watchdog reset, this is erased . How do I RAM Protect this sensitive data from erasure. As this data is modified 10 times every second, I am not in a position to back up this data to EEPROM , due to EEPROM rewrite endurance. In case, I do not use watchdog and the processor hangs, the data loss still becomes substantial. Kindly advice, how to avoid this problem. Thanks in advance.

Regards,

Girish.

  • GIRISH HARI said:
    In case of watchdog reset, this is erased .

    Do you mean the hardware is erasing the RAM after a watchdog reset, or the C run time library start up code is erasing the RAM which contains the sensitive data?

    Are you using the TI or GCC ARM compiler?

    How are the variable(s) containing the sensitive data defined?

  • GIRISH HARI said:
    In case of watchdog reset, this is erased .

    Depending on the compiler you are using, there should be a method of moving the affected variables to uninitialized RAM

    GIRISH HARI said:
    I am not in a position to back up this data to EEPROM , due to EEPROM rewrite endurance

    There are memory types with considerably higher endurance Notably FRAM (effectively infinite) and IIRC MRAM but also battery backed RAM (effectively infinite). These also have much faster write times (and write time alone would prevent you from using TIs emulation of EE).

    Robert

  • Dear Chester,

    The c runtime library is erasing and setting RAM to zero.

    I am using to compiler.

    Some variables are uint8_T, some are floats and doubles,a few are uint16_T and uint32_T. Thanks for the reply.

    Regards,

    Girish

  • Dear Robert,
    This is exactly what I want to know. How are the affected variables protecred?
    There are no FRAM variants in TM4C1294 and battery back up RAM in the hiberation modue seems a good alternative; but how do I use that. Can you or anyone suggest a posting or a link for the same? But for that too,the quantum of my sensitive data is about 1.5 kB.internal battery backup RAM is not so big. What do I do?
    Thanks for the reply.

    Regards,
    Girish
  • GIRISH HARI said:
    The c runtime library is erasing and setting RAM to zero.

    I am using to compiler.

    With the TI compiler the NOINIT pragma may be used to disable the C runtime library initialization of specific variables - see 5.10.18 The NOINIT and PERSISTENT Pragmas

    Given the data is to be persisted in RAM consider:

    a) Adding a CRC / checksum to the data to be able to check if the data is valid when the program initializes.

    b) Having two copies of the data each with their own CRC / checksum. When the data is updated alternate between writing to one of the two copies. This should mean if a reset interrupts an update to one copy of the data, the other copy is still valid.

  • Dear Chester,

    Thanks for your reply. This is not very clear to me. kindly explain. Suppose that i have an array uint8_t Test_array[10]; and i have to set #pragma unint on thios. Kindly do explain, how do I do this.

    Regards,

    Girish.

  • GIRISH HARI said:
    Suppose that i have an array uint8_t Test_array[10]; and i have to set #pragma unint on thios.

    In the C code add a NOINIT pragma like this on each variable:

    #pragma NOINIT(Test_array)
    static uint8_t Test_array[10];
    

    The variables for which NOINIT are used, are placed in the the .TI.noinit section by the compiler. In the linker command file (.cmd) you have to ensure that the .TI.noinit is placed into ram. e.g. add the following to the SECTIONS in the linker command file:

        .TI.noinit : > SRAM
    

  • GIRISH HARI said:
    There are no FRAM variants in TM4C1294

    Very few micros of any kind have FRAM built-in.  I was suggesting using external NVRAM of some sort.

    That would also avoid the EE errata.

    Robert

  • Dear Chester,
    This is the exact solution that I was looking For. Thanks for your Help.

    Regards,
    Girish.
  • Dear Robert,
    Thanks for your suggestion. But the problem in my application, is that there is a lot of floating point arithmetic that's involved and processor execution time is of prime importance to me. Hence using a NVS RAM with I2c or SPI interface is a ruled out option. Parallel NVS Rams are always quite a burden on the pocket and I don't think the final device cost of the finished product would be able to accomodate that cost. But, I would keep that choice in mind.

    Regards,
    Girish.
  • GIRISH HARI said:
    But the problem in my application, is that there is a lot of floating point arithmetic that's involved and processor execution time is of prime importance to me

    I don't see how that's a problem. At a10Hz update rate the processor overhead is essentially nil to keep something like external SPI FRAM up dated.

    Cost is potentially an issue, FRAM is more expensive than EE but that's a tradeoff for orders of magnitude increase in write speed and write cycles.

    Robert

  • Let this serve as "Vote #2" for Robert's suggested (and superior) external FRAM.

    Should the profit margin be insufficient to accommodate FRAM - such "business" is likely too risky for (real) consideration...
  • Hello CB1,
    Its a matter of utter discontentment that a person who is not involved in any sort of technical discussion in the present thread suddenly grabs the center stage and starts rating the answers. This is purely a technical forum and I as a person who has raised the query knows what is best for me. It always remains a best practice not to interfere in others personal affairs and decisions; till the suggestions are sought.Moreover, can Cb1 show anywhere in this thread, had I ever made a mention that this device goes for sale or my profits or losses I would incur to that effect. It is just not a concern of a technical forum like this...I have never rated the answers and sincerely thank both the members for sharing their thoughts. Its just that Mr. Chester Gillon's solutions suits me the best and I have all the rights to arrive at that decision. Mr. Roberts solutions may be excellent; but it does not suit my present need and I am the best judge in this matter and I do not require anyone to ridicule or comment at this decision. Cb1 should know that costs are also involved in devices specially designed to meet our own special purpose requirements and they may be used in in-house research, development, production aid, safety aid, process evaluation or just any other requirement and all designs are just not intended for sale and business. He could be involved in projects for which he may not be financially accountable to anyone; that does not mean that everyone would have that luxury. Even if someone do has the same, I do not wish to squander out resources in not a very purposeful manner.Hence, I wish the forum arbitrators do edit such purposeless postings and maintain the technical framework of this forum.
    Girish.
  • Heh, if you are only doing small volumes that is a stronger argument for using an external FRAM. Development costs swamp BOM costs. The bias in that case is to simple and robust.

    An hour of development time buys a lot of parts

    Robert
  • Dear Robert,

    To Explain the basis for my decision, I need to explain the scenario in detail. This is not in the technical scope of this query, but still, I will explain, only with the intention of solving this confusion; all for once. Other readers, who wish to seek any technical information from this reply may please quit at this point as they would hardly find any in the lines below.

    The project in question below is for our company VRL Logistics Limited()  and these controllers are used in our in-house designed vehicle data acquisition units that collect various engine and vehicle parameters and update the details to our vehicle maintenance server and the data is also shared with logistics group for their trip schedule planning. About 3000 of these units are planned for implementation on our own truck fleet . this is just 3000 units one time requirement and a few more units for spare stock. The controller acquires data from a host of sensors besides 4 serial ports. The net data received in serial port every second itself is about 10000 bytes. These data is to be sorted by calculating standard deviation for seven different variables (parameters)  of which 3 are float and 2 are double float variables.Besides, I have to handle 3 seven segment and one 2 line character LCD Modules. The back-light PWM is to be handled in addition as per ambient light. So my processor cannot afford time. So, I was not bent on serial memory devices. Moreover, the target price for the finished device is Rs.5000/- or about 75USD. Hence, the display consists of 7 segments and character LCDs. Moreover, I do not require the data to be non volatile as I can always upload the data to my servers during power off and retrieve at start up. It is only that the sensor data and the serial port data that we acquire in real time, that should not be lost while we are in the middle of data processing, in events like watchdog reset. I could have as-well used an external RAM for this and retrieved information after watchdog reset. But it is for the time constraint, I am not going for external RAM. The same holds good for FRAM also isn't it? Hence, I made a choice of the other proposal. I told yesterday too that your suggestion was not at all bad, but it was just that it did not suit my preset purpose. Hence, I verified answer stating this exactly matches MY requirement. Means, Its best for me and may not be the same for everyone. Thanks for showing interest in my post.

    Regards,

    Girish.

  • If two - so simple sentences - cause you such distress - might that deserve (some) attention?

    One sentence merely applauded Robert's suggestion of fram - so your venom launched from a "pin-pricking" - at best.

    Did not your (very own writing) reveal - thus INVITE - such financial concern?    G.H.: "I don't think the final device cost of the finished product would be able to accomodate that cost."

    You may note that comments here are not - always & only - confined & aimed at the original poster!   And indeed - offering such "general guidance" has won (many) fans... and formal, published, appreciation from this vendor...