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.

Will this code sequence will always work for Bank 7 ECC hardware selftest for TMS570LC4357 device?

Other Parts Discussed in Thread: TMS570LC4357, TMS570LS3137

Hello Support,

For the TMS570LC4357 device, for testing Bank 7 ECC Selftest, we are supposed to read special OTP addresses 0xF008E3F0 and 0xF008E3F8.

Following is the code sequence I have used :

             ; R1, R2, R7 contents are as shown below before the following code executes

             ; R1 = 0x9ABCDEF3

             ; R7 = 0xF008E3F4

              ; R2 = 0x0

             LDR   R0, [R7, #0x08]

             CMP   R1, R0             ;  Is it always guaranteed to succeed due to AXI Bus Delay for OTP Read Cycle from Cortex-R5?

             BNE   LOOP

            MOV   R0, #0x01

             JMP      SKIP            

LOOP:   MOV  R0, #0

               B  #-8

SKIP:    MOV   R2,  #0x1

 

Sometime is see that the code gets stuck in the "B  #-8" [Infinite Loop].

Do you think because "LDR   R0, [R7, #0x08]" is using AXI Bus, there is some delay required before "CMP R1, R0" instruction?

If yes, some explanation.

Thank you.

Regards

Pashan

  • Pashan None said:
    Do you think because "LDR   R0, [R7, #0x08]" is using AXI Bus, there is some delay required before "CMP R1, R0" instruction?

    No.  Your CPU will stall until the read completes.

  • Hello Anthony,

    Is it necessary to read from the OTP using LDRD instruction or LDR instruction is also fine for the Bank 7 ECC Selftest?
    I am trying to figure out why the above mentioned code is failing sometime.
    Thank you.
    Regards
    Pashan
  • There shouldn't be an issue with the LDR.
    Where did you see instructions to read from the TI OTP?
  • Hello Anthony,

    e2e.ti.com/.../486982
    From John Hall
    Let me know if I am doing some mistake.
    I am really struck.
    Thank you.
    Regards
    Pashan
  • Ok I found the section in the TRM that mentions the 'deliberate' errors in the TI OTP;  section 7.6 page 342 of SPNU563.    But the address range doesn't match what you have above.

    It says:

    You've got an "E" in the address that I don't see in the TRM.

    EDIT: Also, assuming the benefit of the doubt that somewhere this "E" address is documented, then you're trying to check the double bit error location correct?   And just reading this without any special modes turned on?  So that should generate an exception I think.

  • Hello Anthony,

    The document you are showing is for Bank 0.
    For Bank 7 it should be E.
    I sent you the Link for the E2E which contains that information in the previous reply.
    Let me know if you think I have the wrong address.
    Thank you.
    Regards
    Pashan
  • No it is probably the correct address but that answer is for the TMS570LS3137.

    I don't find any mention of this feature for the TMS570LC4357.

    It is probably a lack of documentation on our end but I can't tell you for sure.
  • Hello Anthony,

    Following statements are there in the link : e2e.ti.com/.../533047

    The interconnect runs at a reduced clock rate compared to the CPU.
    So this should amount to a delay of between 10 and 20 CPU clock cycles.

    So, you are confident that whether I use LDR for any 32-Bit word boundary within 0xF008E3F0 -- 0xF008E3FF in any order or sequence, I will always succeed with "CMP R1, R0" instruction even though there is no delay between LDR and CMP as mentioned in the first mail.
    Can you please let me know.
    Because in John Hall's LS3137 Link I see that (uint 64 *) mode should be always used for OTP Read Access, which may be because ECC is always on 64-Bit.

    I am really stuck. Any info will help me a lot.
    Thank you.
    Regards
    Pashan
  • Pashan,

    So I am going to assign this ticket to because the status of the FEE OTP error address (with the "E" in it) is questionable. It's not documented and while it may there it either needs to be in our out of the spec;  right now it's out of the specs and it seems unnecessary.   But Bob will make the call.

    It seems you should be getting an error if you read the double-bit error location so I guess I don't understand the underlying issue in any case.

  • Pashan None said:
    Following statements are there in the link : e2e.ti.com/.../533047

    The interconnect runs at a reduced clock rate compared to the CPU.
    So this should amount to a delay of between 10 and 20 CPU clock cycles.

    So, you are confident that whether I use LDR for any 32-Bit word boundary within 0xF008E3F0 -- 0xF008E3FF in any order or sequence, I will always succeed with "CMP R1, R0" instruction even though there is no delay between LDR and CMP as mentioned in the first mail.

    The CPU will wait for the read to complete.  The other forum post is talking about something else... I think whether the delay in the core compare error check is longer than the time for a write to complete.

    I'm not sure about the assertion of (uint64*) because this entire procedure isn't documented anywhere.   So that's why it's best to pull in as he is the flash expert.

  • I have been working directly with other people in your company on this issue. The read of the single or double bit error locations in the TI OTP do not need to be 64-bit. Even reading a byte will trigger the error. (Because of the ECC all reads of the flash are done as 64-bit reads, but only the part you asked for gets put into a register.)