• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 30 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Source of Cortex-R5F Core errors / properly initializing Flash ECC

jimj2713
Expert 2130 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN, , ARM-CGT, LAUNCHXL2-570LC43

I am receiving run-time ESM Group2-3 faults, which has the datasheet description of "All fatal bus error events. [Commonly caused by improper or incomplete ECC values in Flash.]"

I believe these are in fact Flash ECC faults as the EPC CAM registers are showing added addresses. My original application had multiple memory partitions, and when I reverted back to a single Flash0 partition, the number of CAM addresses went to 1, which suggests partitioning is making this worse. 

I have the CCS project setup to Auto ECC generation -- is there more I should do in CCS to properly load Flash with valid ECC bits?

My CoreEnableFlashEcc assembly code is the same as the code shown in the datasheet, and my setupFlash is the same as the C:\ti\Hercules\Hercules Safety MCU Demos\4.0.0\TMS570LC43x_target_sources\HALCoGen. There is a lot of code in C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0, but there are also many conditional compilations, so it is unclear if different Flash-init functions should be called than the 2 above. Are these the only init-functions required?

Note I am running on the TMS570LC43x development board, and I had to add 3 waits states to FRDCNTL to get anything to execute, if that is relevant. 

Thanks,

Jim

  • 0
    TI__Guru**** 186286 points

    The ECC for flash and SRAM is enabled by default, and cannot be disabled.

    The EPC CAM only captures the address of correctable ECC error from SRAM, CPU and interconnect. It doesn't monitor the Flash ECC error. If you enable SERRENA in EPCCNTRL register, the error flag at ESM 1.4 will be set when the error is capture and EPC CAM index is not full.

    Can you please try the demo example in SafeTI diagnostic library to see if ESM 2.3 is set? 

  • 0
    Expert 2130 points

    The demo-app in C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0\build\TMS570LC4357_NoOS does not compile out-of-the-box (59 errors, and various kinds of errors), and I did not spend time trying to fix it. I will try to get it working. 

    Thanks,

    Jim

  • 0
    Expert 2130 points

    FYI: there are at least 2 missing header-files included by the c-files within the project in C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0\build\TMS570LC4357_NoOS: 

    sl_priv.h and sl_types.h, and there could be more.

    Some of these header files are in C:\ti\Hercules\SafeTI Diagnostic Library\2.3.1, but those demo-apps do not include the LC4357. Can you send me a buildable SafeTI demo-app that can run on the TMS570LC43x development board?

    Thanks,

    Jim

  • 0 in reply to jimj2713
    TI__Guru**** 186286 points

    Hi Jim,

    The latest SDL is version 2.4. Please update your SDL. I compiled the demo without any problem.

    https://www.ti.com/tool/SAFETI_DIAG_LIB

  • 0
    Expert 2130 points

    Thanks. My installation of SDL was 2.4.0, but I renamed it and reinstalled from your link, and the two 2.4.0 directories were different; I don't know where I got the previous SDL2.4.0, but I got it from a TI-link, so maybe there is another version out there? Regardless, now it compiles, but I am using an old version of the ARM compiler (16.9.0 LTS). What is the recommended ARM compiler for the TMS570LC4357? The project in C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0\build\TMS570LC4357_NoOS uses a v5.2.5 compiler, and there are 2 others on ti.com/tool/arm-cgt: CGT-CLANG-1 (1.3.0.LTS) and ARM-CGT-19 (20.2.5.LTS).

    Thanks,

    Jim

  • 0
    Expert 2130 points

    I installed the latest v20.2.5.LTS compiler and updated my CCS10 to the latest. I am trying to run the DemoApp on the TMS570LC43x HDK.

    When the DemoApp runs on the HDK, it hangs in the following code snippet (in HL_sys_startup: _c_int00():

    if(RESET_TYPE_DEBUG != resetReason)
       {
       if(RESET_TYPE_ICSTRST != resetReason)
       {
          / * Memory interconnect selftest */
          SL_SelfTest_MemoryInterconnect(MEMINTRCNT_SELFTEST);
       }

       ...Other stcSelfTestConfigu settings

       _SL_HoldNClear_nError(); --hangs here because SL_ESM_nERROR_Active() returns TRUE forever. Note ESM.SR1 = 0x80000000 (CCM-R5F self-test failed)

    Is there anything I need to configure/define in the DemoApp to run on this target?

    Thanks,

    Jim

  • 0 in reply to jimj2713
    TI__Guru**** 186286 points

    Hi Jim,

    The ESM SR1=0x80000000 can be set by CPU compare error or CCM-R5F self-test error). So please make sure:

    1. The CPU registers (R0, R1...) should be initialized before they are used. Upon reset, not all the MCU registers have fixed value.

    2. don't run CCM-R5F selftest in debug mode. 

  • 0
    Expert 2130 points

    QJ,

    My code has a bug in that Cortex-R5F-Core (ESM group 2, channel 3) occurs and the TI DemoApp code has bug that CCM-self-test (group 1, channel 31) occurs? I was hoping there was example code that properly initialized the TMS570LC4357 on this HDK and ran without error -- does that exist? 

    I am concerned that trying to fix the DemoApp is just a tangent that may or may not be easier than trying to fix my code. If there is not example-code that runs without error, is there an app-note (or can you point me to a section of one of the existing TI documents) that states these 10-20 (or 50) things must be initialized in this order?

    Thanks,

    Jim

  • 0 in reply to jimj2713
    TI__Guru**** 186286 points

    Hi Jim,

    I just run the demo on my HDK, I don't see this ESM error flag. It runs to main() without any issue. 

  • 0
    Expert 2130 points

    I reinstalled everything and I compiled and ran without modification; are you using the v20.2.5.LTS compiler with CCS10? I am also debugging with the HDK-on-board XDS100v2 debugger. Do you think this could be a bad HDK then?

    Thanks,

    Jim

  • 0 in reply to jimj2713
    TI__Guru**** 186286 points

    Hi Jim,

    I will check if I made any changes to the code before. 

  • 0
    Expert 2130 points

    QJ,

    Were you able to check if your demo-project was any different from the project available from download? Alternately can you post / send me your demo-source, and I can try to run it on my HDK?

    Thanks,

    Jim

  • 0
    Guru 92251 points
    jimj2713 said:
    I have the CCS project setup to Auto ECC generation -- is there more I should do in CCS to properly load Flash with valid ECC bits?

    The attached project was created using HALCoGen 04.07.01 for running in a LAUNCHXL2-570LC43.

    It reads the state of the group 2 ESM channels, and report the state using the UART.

    It uses the default HL_sys_link.cmd linker command file created by HALCoGen.

    Using CCS 10.3.0 enabled the "Auto ECC Generation" and "Align program segments to 64-bit memory region (for ECC calculation)":

    I also enabled the "Enable Verbose Output" at the bottom of the Flash Settings.

    The linker map indicates the sections created by linker are not aligned:

    SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    00006938   00006938    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    00006918   00006918    r-x .text
00006940    00006940    00000301   00000301    r--
  00006940    00006940    00000301   00000301    r-- .const
00006c60    00006c60    00000068   00000068    r--
  00006c60    00006c60    00000068   00000068    r-- .cinit

    The verbose output from when the CCS debugger flashed the program was:

    CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR5: Writing Flash @ Address 0x00000000 of Length 0x00006938
CortexR5: Erasing Flash Bank 0, Sector 0
CortexR5: Erasing Flash Bank 0, Sector 1
CortexR5: Erasing Flash Bank 0, Sector 2
CortexR5: Erasing Flash Bank 0, Sector 3
CortexR5: Erasing Flash Bank 0, Sector 4
CortexR5: Erasing Flash Bank 0, Sector 5
CortexR5: Erasing Flash Bank 0, Sector 6
CortexR5: Erasing Flash Bank 0, Sector 7
CortexR5: Erasing Flash Bank 0, Sector 8
CortexR5: Erasing Flash Bank 0, Sector 9
CortexR5: Erasing Flash Bank 0, Sector 10
CortexR5: Erasing Flash Bank 0, Sector 11
CortexR5: Erasing Flash Bank 0, Sector 12
CortexR5: Erasing Flash Bank 0, Sector 13
CortexR5: Erasing Flash Bank 0, Sector 14
CortexR5: Erasing Flash Bank 0, Sector 15
CortexR5: Erasing Flash Bank 1, Sector 0
CortexR5: Erasing Flash Bank 1, Sector 1
CortexR5: Erasing Flash Bank 1, Sector 2
CortexR5: Erasing Flash Bank 1, Sector 3
CortexR5: Erasing Flash Bank 1, Sector 4
CortexR5: Erasing Flash Bank 1, Sector 5
CortexR5: Erasing Flash Bank 1, Sector 6
CortexR5: Erasing Flash Bank 1, Sector 7
CortexR5: Erasing Flash Bank 1, Sector 8
CortexR5: Erasing Flash Bank 1, Sector 9
CortexR5: Erasing Flash Bank 1, Sector 10
CortexR5: Erasing Flash Bank 1, Sector 11
CortexR5: Erasing Flash Bank 1, Sector 12
CortexR5: Erasing Flash Bank 1, Sector 13
CortexR5: Erasing Flash Bank 1, Sector 14
CortexR5: Erasing Flash Bank 1, Sector 15
CortexR5: Erasing Flash Bank 7, Sector 0
CortexR5: Erasing Flash Bank 7, Sector 1
CortexR5: Erasing Flash Bank 7, Sector 2
CortexR5: Erasing Flash Bank 7, Sector 3
CortexR5: Erasing Flash Bank 7, Sector 4
CortexR5: Erasing Flash Bank 7, Sector 5
CortexR5: Erasing Flash Bank 7, Sector 6
CortexR5: Erasing Flash Bank 7, Sector 7
CortexR5: Erasing Flash Bank 7, Sector 8
CortexR5: Erasing Flash Bank 7, Sector 9
CortexR5: Erasing Flash Bank 7, Sector 10
CortexR5: Erasing Flash Bank 7, Sector 11
CortexR5: Erasing Flash Bank 7, Sector 12
CortexR5: Erasing Flash Bank 7, Sector 13
CortexR5: Erasing Flash Bank 7, Sector 14
CortexR5: Erasing Flash Bank 7, Sector 15
CortexR5: Erasing Flash Bank 7, Sector 16
CortexR5: Erasing Flash Bank 7, Sector 17
CortexR5: Erasing Flash Bank 7, Sector 18
CortexR5: Erasing Flash Bank 7, Sector 19
CortexR5: Erasing Flash Bank 7, Sector 20
CortexR5: Erasing Flash Bank 7, Sector 21
CortexR5: Erasing Flash Bank 7, Sector 22
CortexR5: Erasing Flash Bank 7, Sector 23
CortexR5: Erasing Flash Bank 7, Sector 24
CortexR5: Erasing Flash Bank 7, Sector 25
CortexR5: Erasing Flash Bank 7, Sector 26
CortexR5: Erasing Flash Bank 7, Sector 27
CortexR5: Erasing Flash Bank 7, Sector 28
CortexR5: Erasing Flash Bank 7, Sector 29
CortexR5: Erasing Flash Bank 7, Sector 30
CortexR5: Erasing Flash Bank 7, Sector 31
CortexR5: Verifying Flash @ Address 0x00000000 of length 0x00006938
CortexR5: Writing Flash @ Address 0x00006940 of Length 0x00000301
CortexR5: Verifying Flash @ Address 0x00006940 of length 0x00000304
CortexR5: Writing Flash @ Address 0x00006c60 of Length 0x00000068
CortexR5: Verifying Flash @ Address 0x00006C60 of length 0x00000068
CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset

    When the program runs it reports the ESM Group2 channel 3 bit is set:

    esmGetStatus(esmGROUP2,0xffffffffffffffff)=0x8
Starting continuous output

    TMS570LC4357_report_esm_status_over_uart.zip

  • 0 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:
    It uses the default HL_sys_link.cmd linker command file created by HALCoGen

    The HL_sys_link.cmd file created by HALCoGen uses align(32) to give each section in flash 32-byte start alignment:

        .text   align(32) : {} > FLASH0 | FLASH1
    .const  align(32) : {} > FLASH0 | FLASH1
    .cinit  align(32) : {} > FLASH0 | FLASH1
    .pinit  align(32) : {} > FLASH0 | FLASH1

    Where align(32) doesn't result in the sections being padded to 32-bytes.

    Tried changing the linker command file to instead use palign(32) which aligns and pads each section:

        .text   palign(32) : {} > FLASH0 | FLASH1
    .const  palign(32) : {} > FLASH0 | FLASH1
    .cinit  palign(32) : {} > FLASH0 | FLASH1
    .pinit  palign(32) : {} > FLASH0 | FLASH1

    The linker command map file now reports the size of each section has been padded:

    SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    00006ce0   00006ce0    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    00006920   00006920    r-x .text
  00006940    00006940    00000320   00000320    r-- .const
  00006c60    00006c60    00000080   00000080    r-- .cinit

    The verbose output from when the CCS debugger flashed the program was:

    CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR5: Writing Flash @ Address 0x00000000 of Length 0x00006ce0
CortexR5: Erasing Flash Bank 0, Sector 0
CortexR5: Erasing Flash Bank 0, Sector 1
CortexR5: Erasing Flash Bank 0, Sector 2
CortexR5: Erasing Flash Bank 0, Sector 3
CortexR5: Erasing Flash Bank 0, Sector 4
CortexR5: Erasing Flash Bank 0, Sector 5
CortexR5: Erasing Flash Bank 0, Sector 6
CortexR5: Erasing Flash Bank 0, Sector 7
CortexR5: Erasing Flash Bank 0, Sector 8
CortexR5: Erasing Flash Bank 0, Sector 9
CortexR5: Erasing Flash Bank 0, Sector 10
CortexR5: Erasing Flash Bank 0, Sector 11
CortexR5: Erasing Flash Bank 0, Sector 12
CortexR5: Erasing Flash Bank 0, Sector 13
CortexR5: Erasing Flash Bank 0, Sector 14
CortexR5: Erasing Flash Bank 0, Sector 15
CortexR5: Erasing Flash Bank 1, Sector 0
CortexR5: Erasing Flash Bank 1, Sector 1
CortexR5: Erasing Flash Bank 1, Sector 2
CortexR5: Erasing Flash Bank 1, Sector 3
CortexR5: Erasing Flash Bank 1, Sector 4
CortexR5: Erasing Flash Bank 1, Sector 5
CortexR5: Erasing Flash Bank 1, Sector 6
CortexR5: Erasing Flash Bank 1, Sector 7
CortexR5: Erasing Flash Bank 1, Sector 8
CortexR5: Erasing Flash Bank 1, Sector 9
CortexR5: Erasing Flash Bank 1, Sector 10
CortexR5: Erasing Flash Bank 1, Sector 11
CortexR5: Erasing Flash Bank 1, Sector 12
CortexR5: Erasing Flash Bank 1, Sector 13
CortexR5: Erasing Flash Bank 1, Sector 14
CortexR5: Erasing Flash Bank 1, Sector 15
CortexR5: Erasing Flash Bank 7, Sector 0
CortexR5: Erasing Flash Bank 7, Sector 1
CortexR5: Erasing Flash Bank 7, Sector 2
CortexR5: Erasing Flash Bank 7, Sector 3
CortexR5: Erasing Flash Bank 7, Sector 4
CortexR5: Erasing Flash Bank 7, Sector 5
CortexR5: Erasing Flash Bank 7, Sector 6
CortexR5: Erasing Flash Bank 7, Sector 7
CortexR5: Erasing Flash Bank 7, Sector 8
CortexR5: Erasing Flash Bank 7, Sector 9
CortexR5: Erasing Flash Bank 7, Sector 10
CortexR5: Erasing Flash Bank 7, Sector 11
CortexR5: Erasing Flash Bank 7, Sector 12
CortexR5: Erasing Flash Bank 7, Sector 13
CortexR5: Erasing Flash Bank 7, Sector 14
CortexR5: Erasing Flash Bank 7, Sector 15
CortexR5: Erasing Flash Bank 7, Sector 16
CortexR5: Erasing Flash Bank 7, Sector 17
CortexR5: Erasing Flash Bank 7, Sector 18
CortexR5: Erasing Flash Bank 7, Sector 19
CortexR5: Erasing Flash Bank 7, Sector 20
CortexR5: Erasing Flash Bank 7, Sector 21
CortexR5: Erasing Flash Bank 7, Sector 22
CortexR5: Erasing Flash Bank 7, Sector 23
CortexR5: Erasing Flash Bank 7, Sector 24
CortexR5: Erasing Flash Bank 7, Sector 25
CortexR5: Erasing Flash Bank 7, Sector 26
CortexR5: Erasing Flash Bank 7, Sector 27
CortexR5: Erasing Flash Bank 7, Sector 28
CortexR5: Erasing Flash Bank 7, Sector 29
CortexR5: Erasing Flash Bank 7, Sector 30
CortexR5: Erasing Flash Bank 7, Sector 31
CortexR5: Verifying Flash @ Address 0x00000000 of length 0x00006CE0
CortexR5: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
    Note that compared to above CCS is now performing a single aligned write to flash, rather than 3 writes with "gap" between the writes.

    And when the program runs it no longer reports any ESM errors:

    esmGetStatus(esmGROUP2,0xffffffffffffffff)=0x0
Starting continuous output

    This does suggest that just enabling "Auto ECC Generation" and "Align program segments to 64-bit memory region (for ECC calculation)" in the CCS debugger is not sufficient to correctly program ECC.

    Notes:

    1. The modification to the HALCoGen generated HL_sys_link.cmd to change align(32) to palign(32) were not inside USER CODE blocks so would be lost if HALCoGen was used to regenerate the code. I haven't looked for a way to avoid that.
    2. The problem can come-and-go with program changes, as appears related to size of the sections in flash. When first attempted to create the example project in the previous post no ESM group 2 channel 3 error occurred; by adjusting the text strings the program outputs to the UART, and thus the size of the sections in flash, managed to make the ESM error occur.
    3. LAUNCHXL2-570LC43-RM57L_LinkerECCRecommendation is a different possibility to avoid the problem