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.

Clarification about errata DEVICE#B071

Hello,

I am working with TMS570LS31x/21x revision C.

In spnz195z.pdf I  have seen new errata DEVICE#B071.

Issue "Multiple CPU burst write to peripheral registers or peripheral RAM concurrent to DMA transfer may result in  issed write(s)"

(Question 1) I understand that it is any DMA transfer correct? I mean any DMA transfer in any memory concurrent with store-multiple? Correct.

About workarounds:

(Question 2) The second one "Read back and verify after a store-multiple (STMxx, VSTM, VPUSH) instruction concurrent to DMA transactions", just does not make any sense at all! I can not know when the compiler will use a STM instruction so I can not verify it. Also, in case I could verify it, what should I do if it fails? Retry?

(Question 3) About the first workaround "Do not perform a burst write to peripheral registers or peripheral RAM using a store-multiple", I guess that what you mean is that I should use compiler option --no_stm?

(Question 4) But, what if I am using, e.g., CRC module, what needs to write 64 bits at once to registers PSA_SIGREGL1 and PSA_SIGREGH1. Does it means that I need to stop any DMA transfer to do that? 

(Question 5) Is this errata related to errata DEVICE#B064? 

Regards,

Francis.

  • Francis,

    Let me try to clarify some of your questions concerning DEVICE#B071

    Store multiple to peripheral module or peripheral ram are extremely rare. There are some exceptions:

    1] N2HET RAM initialization (using memcopy) Usually this is done during startup and at that time DMA is not yet running.

    2] Using EMIF module to write data externally. This is the real case scenario. According to DEVICE#B064 EMIF write accesses should not use Store multiple. To work around this problem, the compiler option --no_stm can be used. This option works at a c file level and will insure that no STM (or derivative instruction) are generated.

    Your comment concerning the Read back and verify after a store-multiple applies if you are writing assembly code. It is obvious that you can't use this workarounds if C code is used.

    DEVICE#B064 is specific to EMIF module (regardless of DMA transfer in background).

    These erratum apply to all TMS570LS31x/21x part numbers.

  • Hello Jean-Marc,

    I have disassembled my code using tool "armdis" provided with TI Arm Code Generation Tools. Basically I have compiled my code and after that I have used tool "armdis" on every object files that was generated during compilation.

    Basically I can see around 389 STM instructions. Most of them are like

    STMFD           R13!, {R4, R5, R6, R14}

    VSTMDB          R13!, {D0-D7}

    1) I guess that this is not a problem because this is the main ram (and not peripheral module or peripheral ram). Am I correct?

    2) Also as I pointed before CRC module has a 64 bit register which must be written at once, so compiler will use STM instruction. I guess that that means that CRC can not be calculated while a DMA transfer is active, correct?

    3) I assume that this problem is not present in case it is DMA module which is doing a 64 bits transfer to a peripheral ram/peripheral register, correct? (e.g. using DMA to calculate CRC, this is a 64 bits DMA transfer from memory TO peripheral register)

    Regards,

    Francis.

  • Francis,

    1) You are correct. Store multiple to RAM are not affected by this errata.

    2) As it is visible on the Functional Block Diagram on page 5 of the Datasheet (spns62b) the CRC module is single slave module on the main Cross Bar. It is not affected by this errata. 
    One comment on CRC. You are correct when saying that the 64bits register has to be written at once. This cannot be performed with a store multiple. A store double has to be used. (Store multiple will generate 2 distinct 32bits write) and this is not what you want for CRC) DMA can also be used to calculate CRC, using a destination size of 64bits.

    3) When DMA is doing 64bits write to Peripheral Central Resource Bridge and the CPU is doing store multiple to Peripheral Central Resource Bridge than this errata is applicable. For DMA accessing a peripheral memory, the safe way will be to configure the destination address has 32bits. This will allow (if necessary) the CPU to do Store Multiple to peripheral module/peripheral ram and to avoid this errata.


  • Hello Jean-Marc,

    1) Ok, thanks.

    2) I can see that the code that the compiler is generating for writing CRC register is

    000050: E8920018 LDMFD R2, {R3, R4}
    000054: E88E0018 STMEA R14, {R3, R4}

    and the code is working. I would say that this is a multiple store (not store double as you suggested)?

    Would this mean that because this errata this code code should not be run while a DMA transfer is active?

    3) I am not sure if I follow you. You wrote

    "For DMA accessing a peripheral memory, the safe way will be to configure the destination address has 32bits. This will allow (if necessary) the CPU to do Store Multiple to peripheral module/peripheral ram and to avoid this errata."

    But the errata does not say anything about how the DMA is configured, it just says "write to peripheral registers or peripheral RAM using a store-multiple instruction concurrent to DMA transactions". So I do not understand your statement.

    Also, in case we configure DMA and CRC to calculate a CRC of the entire flash (just for safety reasons, to ensure that the flash contents are not changed), the DMA transfer needs to be a 64 bits transfer.

    Regards,

    Francis.

  • Francis,

    The CRC algorithm is based on a 64 polynomial. 
    On each write to the Low or High register, the module will calculate a 64Bit CRC value.

    In your case, using the STM instruction, the CRC module will see:
    1] one 32bits write to the High register and will compute the 64 bits CRC (Padding 0s to the Low register)
    2] one 32bits write to the Low register and will compute the 64 bits CRC (Padding 0s to the High register)

    This will give you a unique signature at the end.

    In opposition, if STRD is used, the CRC will calculate 1 64bits CRC value.

    This will give you another unique signature at the end. This one will be different than the one calculated with the STM.

    If DMA is configured as target 64bits to access the CRC module, this will not impact the way the peripheral modules/RAM are accessed. STM can still be used.

    If DMA is configured as target 32bits to access the peripheral modules/RAM and STM are used by CPU to access the peripheral modules/RAM the errata is not applicable.

  • Hello Jean-Marc,

    1) This question was not for CRC, but for errata DEVICE#B071. I am just using CRC as example because it is the only place where we use store-multiple instructions.

    2) The code

    *PSA_SIGREG = *SourceStart_u64;

    where both are pointers to uint64 is compiled to 

    LDMFD R2, {R3, R4}
    STMEA R14, {R3, R4}

    so it is the compiler who is using store-multiple instead of store double.

    3) I have verified that the generated CRC matches the CRC generated by the linker (basically we are using CRC to verify that the flash does not change)

    4) Now, what I do not understand. In you previous answer you stated:

    "If DMA is configured as target 64bits to access the CRC module, this will not impact the way the peripheral modules/RAM are accessed. STM can still be used.

    If DMA is configured as target 32bits to access the peripheral modules/RAM and STM are used by CPU to access the peripheral modules/RAM the errata is not applicable."

    In both statements you are saying that if there is a DMA (either 64 bits or 32 bits) STM can be used and the errata does not applies. But this is the whole point of the errata, having a DMA transfer concurrent with store-multiple to peripheral RAM or peripheral registers can generate this errata.

    Please, I think that I still need some clarification.

    Regards,

    Francis.

  • Francis,

    As I mentioned in a previous reply, the CRC module is a separate slave module on the Main Cross Bar (Interconnect)
    CRC is not affected by this errata, any kind of accesses can be done to CRC via CPU or DMA.

    If CRC is the only module where Store Multiple are used, than you are not affected by this errata.

    This errata only applies to the modules on the Peripheral Central Resource Bridge. (See picture on page 5 of spns162b)

  • Thanks for your help Jean-Marc. I understand now.