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.

Does DATA Write to Flash Address Space in TMS570LS0432 produce DATA ABORT?

Other Parts Discussed in Thread: TMS570LS0432

Hello Support,

For TMS570LS0432 device assuming MPU is not enabled at all, does CPU writing to Valid Flash Address Space [ATCM Area -- Flash Cell is present in the device for that address being written] produce CPU DATA ABORT?

For TMS570LS0432 device assuming MPU is not enabled at all, does CPU writing to Invalid Flash Address Space [ATCM Area -- But no Flash Cell Present in the device for that address being written] produce CPU DATA ABORT?

Please confirm which one of the above statement is TRUE.

Thank you.
Regards
Pashan

  • Hello Pashan,

      You can't really do a simple write on the ATCM interface to the flash. Writing directly to the flash has no effect on the flash. The flash wrapper will not generate bus error on either the bus1 or bus2 interfaces whether the address is to a valid or unimplemented location. You will need to use the F021 flash API to perform any program/erase operations.

    regards,

    Charles

  • Hello Charles,

    I know that to perform "REAL WRITE" to available valid flash cell I need to use F021 Flash API.

    Question is not a "REAL WRITE" or "REAL PROGRAMMING" of FLASH Cell.

    It's a BUG in the code and it is trying to perform Cortex-R4 DATA WRITE CYCLE to Valid Flash Address Cell using ATCM.
    What happens under that circumstance within Cortex-R4 core even though ATCMECEN Bit of C1 Register within Cortex-R4 is HIGH? Will it produce DATA ABORT?

    Similarly what happens when address is in ATCM space but no valid Flash Cell in the device?

    Assume MPU is disabled.
    Nobody can stop CPU to perform DATA WRITE CYCLE to any address space with a BUG in the code.

    Hope now the question is clear.
    Any information will help me understand the behaviour better.
    Thank you.
    Regards
    Pashan

  • Hello Pashan,

     I did some test and this is what I found:

      1. I confirm that if you write to an implemented address then you will not get a bus error from the flash wrapper. This means that there is no abort.

      2. If you write to an unimplemented address then it depends on the size of the write. If the write is 64bit then there is no bus error either. However, if the write is 32bit then the CPU will be  aborted even if ATCMECEN is not set. The data fault status register shows it is a ECC error. I need to investigate on this one.

      Do you also have the ATCMRMW bit set which is the bit0 of the secondary auxiliary control register. If set, it will cause a read-modify-write operation. The read operation of the RMW is a normal read to the flash. So if this read is from an address which is an illegal address then you will get abort. If this address has ECC issue then you will get ECC error just like any intended reads by your code.

    Regards,

    Charles

     

  • Hello Pashan,

      When the write is less than 64-bit, it will always casue a read-modify-write operation from the processor regardless of the setting of the ATCMRMW. The TCMs support the use of an error checking scheme implemented in the memory controller outside of the processor. The ATCMRMW is used to support this external error block by ensuring that it is always 64-bits of data that is written to the TCMs, independent of what data width the instruction implies.

      The reason that a less than 64-bit write to an unimplemented address will lead to an abort is becasue this write implies a read-modify-operation. Reading from an unimplemented location returns unknown data and this causes an ECC error detected by the processor.

    regards,

    Charles

  • Hello Charles,

    Thank you for the exact explanation along with ATCMRMW Bit behaviour.

    Regarding 64-Bit Write Cycle :
    1> STRD Cortex-R4 Processor Instruction will be considered as 64-Bit WRITE Cycle I suppose
    2> STM is also considered as 64-Bit WRITE Cycle or 32-Bit Write Cycle? Even though CPU is a 32-Bit BUS processor.
    Please confirm with your elaborate e-mail.
    Thank you.
    Regards
    Pashan

     

  • Hello Pashan,

      1. yes, the STRD will be considered as 64-bit write. The STRD instruction will take two source registers and write to the destination address. For example, STRD R0, R1, [R2] where the R0 and R1 form one 64-bit data to be written to address at R2.

      2. If you do STM with two or even number of registers like STMIA R0, {R1-R2} then the R1 and R2 will be formed as one 64-bit data before written out of the TCM. But if you do STMIA R0, {R1-R3} then the processor needs to break up into one 64-bit write with R1 and R2 as one 64-bit data and another 32-bit write with only R3. The second write will involve read-modify-write operation and if this read is to an uniplemented location then the flash wrapper will assert bus error and unknown data could be returned resulting in an ECC error to the processor.

    Regards,

    Charles

  • Hello Charles,

    Can you please explain then what is the purpose of ATCMECEN Bit from user perspective?

    Is it a DON'T CARE or it is used only for ATCM Read Access Error condition?

    From your description it looks like ATCM Write Access Error Condition is not at all controlled by ATCMECEN bit.
    Any detailed description of ATCMECEN bit w.r.t. Error Conditions [Write Cycle/Read Cycle] [Valid Address/Invalid Address] within ATCM Address Space will help me understand better.

    Thank you for your previous detailed replies.
    Regards
    Pashan

     

  • Hello Pashan,

      Thanks for your patient. I did some more tests. I perform some 32-bit STR and LDR to the ATCM unimplemented address location and below is what I got.

    Sr.  TCMPEN TCMECEN STRD STR LDR
    1 0 0 no abort no abort no abort
    2 0 1 no abort abort abort
    3 1 0 no abort abort abort
    4 1 1 no abort abort abort

     Case 1

        This makes sense in all three different type of operations becasue neither the ECC nor the external error is enabled. Case 1b: STR

      Case 2a: STRD

         The STRD is a 64-bit write to the flash wrapper. As I mentioned the wrapper ingores the write and does not generate bus error and hence no abort.

      Case 2b: STR

        This is a 32-bit write. Read-modify-write was introduced. Reading from the unimplemented address casues an external error and this becomes an abort even though that ECC is not enabled.

     Case 2c: LDR

       This is again a read to an unimplemented address. With the TCMECEN set, a bus error is sent and recognized by the processor.

      Case 3a: STRD

       This is a 64-bit write. Again, the flash wrapper ignores writes and does not generate bus errors and hence no abort.

      Case 3b: STR

       Read-modify-write was performed. The read from an umplemented address can return unknown data. Since ECC was enabled, we see ECC error detected by the CPU and abort.

      Case 3c. LDR

       TCMECEN is disabled here. But abort is still observed. This means that the unkonwn data returned from the umimplemented address causes the ECC error and abort.

     Case 4a: STRD

       Same as 2a and 3a.

     Case 4b: STR

       The read of the read-modify-write operation should cause both bus error to be generated and ECC error to be detected. Both errors are happening. Here it looks like the Data Fault Status Register only captures the ECC error. I was getting a 0xC09 value in the register.

      Case 4c: LDR

       Similar to the 4b. The read should cause the flash wrapper to generate bus error. The data returned from an unimplemented address causes the processor to detect ECC. But the DFSR captures the ECC error.

      When I do the same 4 cases to an implemented address I don't get any abort. My implemented space does contain proper ECC.

      Let me know if this clarify.

    Regards,

    Charles