• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 533 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.

TMS570LS3137: Abort_Handler() exception after setting ACTM ECC check on SRAM

Chuck Wong
Genius 3950 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Hello there,

I'm quite a bit of trouble making the SRAM ECC to work, and this since a while. 

We’re using the TI MCU TMS570LS3137 with an ARM CORTEX-R4F core and having constant problem with MCU RAM ECC even bank and/or odd bank parity-check enabled before the C main() is called. In the following code, please note that if only bit25 is enabled for the Flash ROM ECC check, no problem at all. The problem is when Bit26 and/or Bit27 for RAM ECC check were enabled.

        ; Enable ACTM ECC (spnu499c TRM para. 2.2.3.2)
        ; DDI0363G TRM para. 4.3.16: c1, Auxiliary control register ACTLR
        ; Configure to enable ECC check on Flash and SRAM

        MRC     p15,#0,r1,c1,c0, #1             ; Read Auxiliary control register
        ORR     r1, r1, #0x0E000000             ; Bit25 is ATCM ECC check enable (main flash array)
                                                ; Bit26 is B0TCM ECC check enable (SRAM even bank)
                                                ; Bit27 is B1TCM ECC check enable (SRAM odd bank)

        MCR     p15,#0,r1,c1,c0, #1             ; Write Auxiliary control register
        nop
        nop
        nop

The following list provides a summarized description of the encountered problem and we’re seeking your helps:

  1. Using binary code generated by IAR linker with the TI supplied startup code in tms570ls3137_cstartup.s.
  2. When using Debugger to start the code, problem has never happened.
  3. With the same binary code in the MCU Flash, disconnect the debugger and recycle the power will enter the Abort_Handler() exception every time, which signals "illegal memory read/write access".
  4. By “Attach to the running program” then stop the execution, the following is shown:

  1. Data fault address DFAR and status DFSR registers display different values on each occurrence, so I cannot get a hold on the origin of the trouble.
  2. When stepping code before reaching the main(), I came across the following behavior:

  1. When __iar_data_init3 was called, I stepped into a deeper level and have discovered that when the green line was executed within __iar_zero_init3, the Abort_Handler() exception is entered, which signals that was a RAM parity error encountered:

To summarize, the following is the complete calling sequence:

tms570ls3137_cstartup.s (SRAM ECC check enabled here), branch to 
__cmain, calls
__low_level_init, calls
__iar_data_init3, calls
           __iar_zero_init3, executes
                first call to STR.W instruction, no issue
                second call to STR.W instruction, no issue
                third call to STR.W instruction, illegal memory read or write
                      bring up Abort_Handler() exception

Could you provide hints as on what I should look for to prevent the RAM ECC check exception?

Thank you!

  • 0
    TI__Guru**** 196776 points

    1. Is there error when performing SRAM PBIST test before enabling the SRAM ECC?

    2. Is the SRAM initialized before the SRAM ECC is enabled?

    3. Did you perform the SRAM ECC selftest (1-bit/2-bits ECC fault injection)? After selftest, the error flags should be cleaned.

    4. Is the SRAM ECC problem occurs on only one device or more devices?

    5. Did you try the sys_startup.c generated by HAlCoGen? 

  • 0 in reply to QJ Wang
    Genius 3950 points

    Responses to your questions:

    1. No the SRAM PBIST was not performed, although this is scheduled later in the code after main(), but never reached.

    2. Hmmm, this might be the cause ... Could you please let me know how to initialize the SRAM, reference to spn etc.?

    3. No, SRAM ECC selftest was not performed. Where may I find this information regarding its necessity and utility?

    4. Yes occurred on every device.

    5. No, as we're not using any generated C code.

    The software does initialize many MCU devices RAM after entering main() in my C code, for RAMs allocated to DMA, VIM, N2HET1, DCAN1 and MIBADC1, because those devices are being used in the application.

    With reference to the MCU device datasheet spns162c Table 6-25. PBIST RAM Grouping, are all ESRAM1, ESRAM5, ESRAM6 and ESRAM8 needing hardware initialization?

    By reading your questions, I get a feeling that I need to initialize those parts of the SRAM to have their ECC/parity calculated before using the RAM, but have to be done before execution of any user code/linker data initialization, so way before the main() entry point. Am I right? If so, could you just point me to where I should look at, and how to do that before main()?

    Thank you.

  • 0 in reply to QJ Wang
    Genius 3950 points

    Thank you!

    It works in this order as in the provided MCU initialization guide:

    25. Start a self-test on the CPU RAM using the programmable built-in self-test (PBIST) controller and wait for this self-test to complete and pass (Section 2.20).

    26. Initialize the CPU RAM using the system module hardware initialization mechanism so that the ECC region for the CPU RAM is also initialized (Section 2.21).

    27. Enable the CPU's Single-Error-Correction Double-Error-Detection (SECDED) logic for accesses to CPU RAM memory (CPU's B0TCM and B1TCM interfaces) (Section 2.22).

    Best regards,