• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 1242 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.

CCS/TMS320F28377S: #pragma PERSISTENT /NOINT precompile directives in CCS

Nick Amos
Prodigy 140 points
Part Number: TMS320F28377S


Tool/software: Code Composer Studio

Hi

I am trying to use the #pragma PERSISTENT  /NOINT  precompile directives in CCS to prevent a variable from being initialized or reset during a watch dog interrupt 

However I have tried various combinations  - it did compile but when I test the presistence of the variable during debug sessions, after the watch dog reset my test values

also got reset to zero again.

I used variations of precompiles such as 

#pragma PRESISTENT(x)

Uint32 x = 0;

#pragma PRESISTENT

Uint32 x = 0;

also tried 

#pragma NOINT(x)

Uint32 x = 0;

#pragma NOINT

Uint32 x = 0;

Please advise how to do this for  CCS/TMS320F28377S 

Thanks

  • 0
    Prodigy 140 points
    Is there any documentation available related to the use of #pragma as it relates to CCS/TMS320F28377S environment?
  • 0 in reply to Nick Amos
    TI__Mastermind 19810 points
    Nick,
    below links will be helpful to look at.

    processors.wiki.ti.com/.../Category:Code_Composer_Studio_v7

    processors.wiki.ti.com/.../TI_Compiler_Information

    On this device, the device boot ROM zero initializes the RAM when coming out of a POR or XRSn reset, the watchDOG reset also triggers an XRSn so the RAM is zeroed out. please take a look at below forum post if you need to have some data retained across a watchdog reset

    e2e.ti.com/.../2226459


    Hope this helps.

    Best Regards
    Santosh Athuru
  • 0 in reply to Nick Amos
    Prodigy 140 points
    Hi Santosh,

    Thanky you - OK this is not good at all - can the Boot loader code be modified - is it OTP /ROM based?

    How can we get this changed - there must be a better way than having to redesign the PCB to accommodate register persistancy.
    Any external flash/eeprom has a finite amount of write life as you know. Yes I do have EEPROM on I2C but that is slow keeping track of
    realtime events and will destroy the external eeprom/ flash eventually.


    I would have hoped to see a Boot loader implementation that would allow or disallow memory resets.

    Please advise
  • 0 in reply to Nick Amos
    TI__Mastermind 19810 points

    Nick,

    The boot loader is in device ROM and this cannot be bypassed. How much RAM/Data are you trying to keep in context across the watchdog reset? And the watchdog reset scenario in your design is not a true error reset (run away code or code not executing as pre-defined or in a pre-defined pattern) but you by need trigger/use watchdog just to reset the MCU?

    I'm thinking if you could use any other reset to reset the device from SW that doesn't erase the RAM on boot up.

    Best Regards

    Santosh Athuru

  • 0 in reply to Santosh Athuru
    Prodigy 140 points
    Hi Santosh,

    No the issues are not WD related - in any event we need to guard against stack corruption etc. which will happen and we have seen it already.

    That said, if ciritcal state variable is lost it means that. Lets say you have to count the number of items to go into a container, and the system
    experience a stack corruption, if the bootloader resets the system we have no way to recover from this glitch.

    The idea would be to write the hypotetical value to memory with a time stamp and checksum in duplicate form. If the system crash, we can retrace our state by extracting the last updated validated value stored in memory. If both state variable do not checkout correctly through checksum verification we may assume that a cold boot took place.

    Now the application is for automotive high speed decision making and with all the overhead as outlined above would be appropriate to be able to work with memory directly.

    We very much would like to see a small block of ram not initialized by the bootloader and possibly not initialized by the c startup code via a
    #pragma directive. An area of say 1000 words would be good.

    Kind Regards
  • 0 in reply to Nick Amos
    TI__Mastermind 19810 points

    Hi Nick,

    Thanks for the details, I understand your use case, we debated similar use-cases when choosing the design as such. We do have at least 2 32 bit locations (registers) that are not reset on XRSn that can aid in debug and can be used to store the status information. You should be able to use this to keep the status of execution in these variables. 

    I'm checking with team if users can use first few locations in PIE RAM to keep any extra debug information, we do re-purpose these locations for EMUBOOT but if user is not using EMUBOOT or setting the device to boot to flash then these can be used.

    The only other way to be able to store large context is to save it in external memory which is not reset or cleared when the MCU is reset.

    Best regards

    Santosh Athuru

  • 0 in reply to Santosh Athuru
    TI__Guru 60865 points
    Hi Nick,

    Did we reach a resolution here, or do you still need additional info from Santosh?