• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 751 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.

Peripheral RAMs: using as temporary data storage, which is the "best"?

Jarkko Silvasti
Expert 1395 points
Other Parts Discussed in Thread: HALCOGEN

Hi,

I used CAN RAM to store certain data to survive TCM RAMs PBIST&Init... CAN RAM worked well when I had a small amount (8 bytes) of data to store, then I figured after testing and extensive reading of data sheet & TRM that usage of peripheral RAMs is not so trivial as it first seemed based on the data sheet...

Looks like also that using TCM RAM is not possible even with linker mapping because SL_Init_Memory() only has 1 argument descriptor (RAMTYPE_RAM) for whole TCM RAM. PBIST has splitted the RAM in half PBIST_RAMGROUP_06_ESRAM1 and PBIST_RAMGROUP_21_ESRAM5 so PBISTin should be doable but not initialization.
- So it is not possible to reserve space with linker from ESRAM1 to normally hold the struct to be backupped and then manually copy it to ESRAM5 and then do PBIST & memoryinit for ESRAM1 and copy the backupped data back to ESRAM1 and then make PBIST & init for ESRAM5


It this interpretation correct for peripheral RAMs concerning CAN, ADC & N2HET (just checked a couple of them)?

CAN3: 0xFF1A_0000 - 0xFF1B_FFFF, actual size 2KB (wrap around if unimplemented address)
- this means that you need to dig out from TRM how much of that 2KB block is implemented and how it is implemented
- TRM 24.5.4: Looks like that every message object (0x20 size == 8*32bit) only the first 4 32bit blocks can be written, offset 0x10 allows also lsb byte to be written and rest of it is more or less reserved
- So one message object can "easily" store 16 bytes (4x32bit) if not counting that lsb byte from 0x10 offset.
- CAN looks to have 64 message objects to total storage space 64*16bytes=1024 and every other 16byte area must be skipped when writing & reading

I assume that in RDA mode the TRM 24.5.2 mention about message object64 (address 0x0000) is meaningless and also that part of the RAM can be used freely....

What TRM 24.5.4 means "The CPU has access to one word line at a time only.", looks to be possible to write 32bit at once like this

sl_canREG3->CTL = 0x00000481U; /* Disable parity, TEST mode, init mode,  */
sl_canREG3->TEST = 0x00000200U; /* Enable RAM Direct Access mode */
#define canRAM3_PTR ((volatile uint32 *)0xFF1A0000U)
*(canRAM3_PTR+0) = 0xAABBCCDD;

And also it looks like to be possible to write with 8bit pointer byte by byte
    #define canRAM3_PTR_8bit ((volatile uint8 *)0xFF1A0000U)
    *(canRAM3_PTR_8bit+0) = 0x11;
    *(canRAM3_PTR_8bit+1) = 0x22;
    *(canRAM3_PTR_8bit+2) = 0x33;
    *(canRAM3_PTR_8bit+3) = 0x44;
    *(canRAM3_PTR_8bit+4) = 0x55;
    *(canRAM3_PTR_8bit+5) = 0x66;
    *(canRAM3_PTR_8bit+6) = 0x77;



ADC2: 0xFF3A_0000 - 0xFF3B_FFFF, actual size 8KB (wrap around if unimplemented address)
- this means that you need to dig out from TRM how much of that 2KB block is implemented and how it is implemented
- looks like 64 channels == 64*32bit address and only lower 16 bit of each 32bit datafield can be written, upper 16bit is always 0
- Total data storage 64*2bytes == 128 bytes if using 16-bit data packing and 64bytes if writing only lsb byte.

TRM 20.9.2: "Only 32-bit reads and writes are allowed to the ADC results RAM in this test mode."
- this prevents writing byte by byte

N2HET: Then I though that N2HET would be at least "full consecutive ram" but looks like that it isn't either and has also some accessing restrictions
TRM 21.2.2.1: only 32 bit writes allowed, every 4th address is reserved which should not be accessed


As it looks to require rather deep looking to find out properties of each peripheral RAM I think that CAN RAM is rather easy to use and quite much data can be stored, just make a structure for the you want to store and then store it manually (almost like memcpy()) byte by byte by using 8bit pointer and when 16 bytes are stored increase ten destination pointer by 16 to skip that "reserved area of message object" and repeat until out of data. Restoring the data from CAN RAM should be as easy by using same 8 bit pointer. Only limitation is that implemented area which means 1024bytes which is rather large, if more data is stored and beginning of the data is over written.
- is this correct, and there is no need to wait anything when init mode bit is set in CTL register?
- since this is safety related data, CRC from the data should be calculated and added to end of actual data or at least use parity checking in CAN RAM (but would it require memory init for CAN RAM first if not writing full 32bit blocks with 8 bit pointer)?


Will there be more simpler peripherals RAMs to use for backupping the data which is in both RM44 & RM48 series? Didn't look about VIMRAM because in case of debugger reset at least FIQ can come through so don't want to corrupt vectors...

  • 0
    TI__Guru**** 196566 points
    Hello,

    You can use either external SPI FRAM or EMIF SRAM to backup data from ESRAM. The peripheral RAM is not intended to be used for backup ESRAM data. But you can use DCAN RAM for this purpose if you configure it properly to avoid any conflicts with the message handler.

    It's better to init the memory at startup and enable the parity checking when using it.

    Regards,
    QJ
  • 0 in reply to QJ Wang
    TI__Guru 59540 points
    QJ,

    The point is that the data to be backed up is safety related so external RAMs (either SPI based or EMIF based) would need to be ECC, parity, or checksum protected.

    Jarkko,

    To get to a more basic question on what you are doing. Why do you need to copy/backup data? Are you going to run PBIST after your application has already started? Generally we PBIST at startup first thing and rely on ECC after that. Is this an issue related to the operational profile requiring very long run time between power downs? Usually, ECC alone, is still sufficient in these cases when combined with the CPU lockstep protection for the ECC logic. Let me know and we can discuss in more detail.
  • 0 in reply to Chuck Davenport
    Expert 1395 points

    Hi,

    According to the suggested/recommended CPU initialization order there are some (SafeTI) tests (STC, CCM, pbist ROM (fail&pass cases)) done before TCM RAM PBIST phase. Also if I understood correctly not all possible failures require to halt the cpu (for example init phase 7 - checking ESM group3 faults says clearly that halting is more than recommended but same is not said for other) but this is something which is not said very clearly.

    I would like to store the results & information of the tests (and maybe reset reason etc) performed before TCM RAM PBIST so in case there is a failure which does not require halting the CPU we can inform the user about broken device rather than having the device which is just silent inside infinite-loop.

    So my primary object is to use this backup in bootup only not in actual running...

    I implemented that DCAN RAM  write16byte - skip 16 - write another 16... pattern with CRC (CRC is calculated before writing data to DCAN RAM) and it looked to work.

  • 0 in reply to Jarkko Silvasti
    TI__Guru 59540 points
    Hello Jarkko,

    Thanks for the detailed explanation of your intended goal of saving the data. I think this is a creative use of the peripheral RAM as long as there is sufficient amount of space for it. For sure, I would include a CRC on top of the CAN RAM Parity protection. You may also consider using the Flash Emulated EEPROM (FEE) to eventually store this information but the FEE operation on startup would be too much without going through all the safety checks first and would slow down the startup as well.

    Also, some of our devices have SRAM split between power domains and can, therefore, be ran separately for each block. This is something to look at for your specific device but would require some customization of the HalCoGen drivers to do so. I don't recall which device you are using so I can't confirm if this is an option that might be available to you.
  • 0 in reply to Chuck Davenport
    Expert 1395 points

    Is there really need to use parity together with CRC (for SIL3), maximum of 1024 bytes (we are currently using like 16 bytes (which could be stored also to CPU registers)) should be well protected by 32bit CRC (will there even be a straight answer for this :))? If yes then:
    - is there a need to PBIST the DCAN RAM before using it - this isn't parity depended, is there some need to perform this always, some kind of error what CRC can't handle?
    - is there a need to do parity testing before using it?
    - is there a need to also initialize DCAN memory with parity enabled in order to get parity working (not planning to read before writing)? Does the initialization requirement depends on do you write "complete 32 bits values" say like 32byte stream instead of 30 byte stream

    And I'll guess that after restore, if parity is used, you need to also manually check the ESM channel that parity error is not active.

    I am using both RM44 and RM48 (2 different products) so it would be more than welcome to have same routine in both to minimize the work. FEE cannot be used as it is used in another product. I think I am happy with that DCAN, it is not used for anything else (so I do not need to worry about debugger reset situation) and that 1024 bytes is more than enough for us.

  • 0 in reply to Jarkko Silvasti
    TI__Expert 6985 points
    Jarkko,

    Some things to consider:

    PBIST is good at catching "fault accumulation", please consider the case where you didn't restarted the device for multiple years and didn't accessed the DCAN RAM for a long time. In this case there is the possibility that multiple faults have build up and depending on the CRC polynome you have chosen you might not be able to catch these. This is very theoretical, but should illustrate what PBIST is good for.

    PARITY on peripheral RAMs, please note the peripheral parity check is performed with the memory itself, it doesn't cover the buses between the CPU and the memory. This means that this isn't monitored by the lock-step and you might want to perform a "Software Test of Parity Logic", again this helps with "fault accumulation".

    Again a theoretical case, but please consider a fault where the memory always reads as all '0' in this case the CRC would be '0' to if not seeded with a different value.

    My personal feeling is that when dealing only with such a small amount of data (16 bytes) you might be better of with simply storing the data twice (inverted). Then you could easily change the data, without having to recalculate the whole CRC.

    Best Regards,
    Christian
  • 0 in reply to Christian Herget
    Expert 1395 points
    Thanks for the tips, have to consider what is enough. So the things are as I feared that there are no explicit answer what should be done and how in order to full fill thing Y (SIL3 in this case), it depends on this and that.

    So basically, PBIST&parity&crc for data&inverted data&inverted crc all together is for sure enough, but most probably something "less" is also enough to full fill the need for Y. Maybe I just then implement at least the PBIST and maybe add parity as those check have already been done in later phase of the init so it will be more or less copy&paste to add those here for this 1 RAM. Or then just store the CRC also as in inverted format or something so 2 CRC values...
  • 0 in reply to Jarkko Silvasti
    TI__Guru 59540 points
    Hello Jarkko,

    To define which methodologies would be best I think you have to take a step back and analyze the use of the RAM. First, if we prescribe to the safe island philosophy that we use in Hercules, the first step is to use PBIST to prove the validity of the RAM that is to be used with a diagnostic coverage of High, then once proven good to use, some other mechanism or mechanisms to protect the data during writing and/or reading the data. Performing a readback of the written data during the transfer would provide protection of the data in the transfer step, and using CRC would provide protection of the data during readback. Both of the two latter mechanisms would also provide a high DC so know you have a complete high diagnostic coverage of the storage element and the data to be stored.

    Of course, what comes to mind now is what is the criticality of this data to the safety function? If it is not really critical to the safety function then perhaps there can be a made an argument that this level of protection may not be necessary. I believe that the assumption that was made in the safety diag library was that this data wasn't critical to the safety function since you would take action immediately upon any one failure point and therefore no need to save pass information given on could assume that reaching the PBIST would mean that all prior tests had passed successfully. This is a behavior that you or someone on your team would need to define relative to your system level safety requirements since we don't have the application level visibility to judge this.