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.

TMS570LC4357: Interconnect time-out by EEPROM accesses

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hi,

My customer is reporting an issue with EEPROM access using FEE driver generated HalCoGen.

Issue:
SCM time-out error is generated (ESMSR7 = 0x0800000) and CPU stops working.
When the issue happens, CPU repeatedly writes and reads 128 blocks of data (1 block=40bytes) to/from Flash bank7.
Here is all register dump after the issue.
registers.xlsx
ESMSR7 register is line#2878. The value is 0x0800000 which means “SCM Time-out Error”
I checked SCM registers (line#3160 to #3166) and found SCMIAERR1STAT=0x00000060.
This means “Request to Response Timeout” at IA5 and IA6.
According to TRM table 4-4, IA5 and IA6 are “CPU AXI-M Read” and “CPU AXI-M Write”, respectively.
TRM section “4.3.5 Interconnect Timeout” tells me they are accept-to-response timeout at these IAs.

Questions:
1) What is the cause of these timeout error? Is there any information to debug further?
2) According to customer, CPU stops working after the error. I guess this is simply because the error is not cleared.
If so, what should be handled by customer application? Below steps are enough?
i) write 0xA to SCMCNTRL[3:0] to clear SCM error
ii) write ‘1’ to clear corresponding bit in ESMSR7
Any other points need to be checked?

Thanks and regards,
Koichiro Tashiro

  • Hello,

    SCMIAERR1STAT=0x00000060.

    R Scm_ScmIaStat 0x0000000B 0x00001020
    R Scm_ScmTaStat 0x0000000B 0x00000004

    The timeout happen to IA5 and IA6: CPU AXI-M Read and Write

    There are pending transaction IA5, and IA12: CPU AXI-M Read, and CPU PP-AXI

    and pending transaction on TA2. L2 Flash Port B

    I don't see any ECC/parity error in flash port B.

    I am not sure what triggers the error, I will check other registers later.

  • Hello Koichiro,

    When your customer performs FEE read and FEE write, is TI_Fee_MainFunction() function called to finish the async read/write operation? Is the wait state programmed properly? If HCLK>= 135MHz, the EWAIT is 8.

  • Hi QJ,

    Sorry for the late reply.
    Please see answer from the customer.

    When your customer performs FEE read and FEE write, is TI_Fee_MainFunction() function called to finish the async read/write operation?

    Yes. Customer called TI_Fee_MainFunction() after the async read/write.

    Is the wait state programmed properly? If HCLK>= 135MHz, the EWAIT is 8.

    Customer uses HCLK=150MHz.
    EWAIT is configured as '9' (not 8). It seems F021 Flash library uses this value.

    Thanks and regards,
    Koichiro Tashiro

  • You are writing 128 block of data to EEPROM, and each block is 40bytes. Each block has 24 bytes block header, the total size of the data blocks is 128*(40+24)=8192Bytes=8kB.

    When you issue FEE write operation, the FEE driver checks if there is enough space in the current virtual sector. If there is insufficient space in the current Virtual Sector to update the data, it switches over to the next Virtual Sector and copies all the valid data from the other Data Blocks in the current Virtual Sector to the new one. After copying all the valid data, the current Virtual Sector is marked as ready for erase and the new one is marked as Active Virtual Sector. Any new data is now written into the new Active Virtual Sector and the Virtual Sector which is marked as ready for erase will be erased in background.

    What is the size of the virtual sector? If the virtual sector is 4KB (1 flash sector), the driver may keep erasing virtual sector and programming the data.

    For example, you have programmed block #1 to block #63 to virtual sector #1 (63 * 64 = 4032 bytes, the header size of virtual sector is 32 byes, so only 4096-4032-32=32bytes left), when you issue a command to write block #64 (64 bytes), FEE driver will copy block#1~block#63 to next virtual sector #2 since there is not enough space left. After copying block#1~63 to VS#2, it tries to write block #64. Since there is not enough space in virtual sector #2 for block #64, all the blocks are copied back to virtual sector #1 again, then virtual sector #2.