• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 546 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.

TMS570LC4357: ESM Group 2 channel 3 error because of "Speculative Instruction Fetch" operation issue

Zonguldak's Rose <3
Prodigy 141 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hi there,

I have 2 different project working on TMS570LC4357 MCU.

On my first project, I'm using freeRTOS and cache is enabled (write-through) for flash memory. On the second project, I don't use freeRTOS, but the cache settings are the same.

On my first project I'm getting an error from ESM group 2 channel 3 even when cache is disabled. I think this error is getting because of speculative instruction fetch operation and in this case I know that 2 different solutions. But my second project doesn' recieve any esm error (actually when I do flash bank 7 write operation, esm error recieves). What could be the difference?

According to the ARM Cortexv7-R manual, the CPU uses speculative instruction fetch, but in this case this error should occur in both projects. Both projects are too large, so there must be an ecc error depending on the speculative instruction fetch operation.

Is there any known issue with using freertos specifically and why is it related to using flash bank 7 or fapi?

  • 0
    Prodigy 141 points

    Hi,

    I've done some other tests and I realized something different situation.

    I separated .text section and flash api library and placed into different area of flash bank. So that I configured these area differently. My test configuration and results are below.

    Note: I'm using vfill for test configuration. I know using vfill is not recommended in this case but I'm trying to understand differance behavior between Rtos and Bare-Metal projects.

    1) Cache settings of Flash area: Enable, Write Through.

        Cache settings of Flash api area: doesn't matter.

    • FreeRTOS project always receives ESM 2.3 error. Number of esm error increase with time.
    • Bare-Metal project recieves ESM 2.3 error when doing eeprom operation (using fee and flash api).

    2) Cache settings of Flash area: Disable.

        Cache settings of Flash api area: Enable, Write Through.

    • Receives a few error at the beginnig of code and stops (both of the projects). Number of esm error constant.

    3) Cache settings of Flash area: Disable.

        Cache settings of Flash api area: Disable.

    • FreeRTOS project always receives ESM 2.3 error. Number of esm error increase with time.
    • Bare-Metal project recieves ESM 2.3 error when doing eeprom operation (using fee and flash api).

    In 3. configuration, ıf don't any eeprom operation, esm error doesn't receive for both of the project.

    It seems FreeRTOS kernel and eeprom operations causes additional errors. If speculative instruction fetch operation causes ESM 2.3 error, why bare-metal project doesn't recieves any error from 1. and 3. configuration and why recieves esm error when trying some eeprom operation.

  • 0 in reply to Zonguldak's Rose <3
    TI__Guru**** 196306 points

    ESM 2.3 indicates incorrect ECC values in Flash.

    The ECC values for all of the Flash memory space (Flash banks 0 through 6) must be programmed into the Flash before the program/data can be read. This can be done using linker cmd file.

    https://software-dl.ti.com/hercules/hercules_docs/latest/hercules/How_to_Guides/HowToGuides.html

    The bank 7 is a data flash. Did you program your code to bank 7?

  • 0 in reply to QJ Wang
    Prodigy 141 points

    Thanks for answer.

    What is the meaning "Did you program your code to bank 7" . I'm using flash bank 7 for storage only data. My project doesn't generate ECC from linker file. I think this not be safety because TI doesn't give enough detail. Additionaly I'm using vfill instead of fill and I know if I use fill instead of vfill, there will be no error. My problem isn't that.

    "The ECC values for all of the Flash memory space (Flash banks 0 through 6) must be programmed into the Flash before the program/data can be read. This can be done using linker cmd file." Is this issue related to speculative instruction fetch or just the Flash ECC value?

    • There are many empty sector into the flash memory. In running time, CPU does not generate any operation on this area (Instruction or data fetch operation) but ECC must be programmed correctly even if this area is empty. When I don't use this area, why does ECC generation and calculation mechanism want  correct ECC value for my empty location. Doesn't the ECC mechanism only use my valid flash area?
    • This issue related with my configuration. I program the MCU in the same way for all 3 configuration and don't do any ECC related operation. In this case, why ESM 2.3 error count is different (per second). If it is only about Flash ECC value, MCU must recieve same ECC error number per second.
    • FreeRTOS project receives ECM 2.3 error during run time whether Flash emulation using or not. What is the different. Does FreeRTOS kernel cause any Flash ECC operation?
    • Flash bank of tms570ls3137 mcu contaion 0xff value when sector is ereased and empty but tms570lc4357 mcu containt different value.
    • If all of the flash bank area must be programmed with correct ECC value, why am I do some additionally operation? CCS or linker file generated by halcogen should do that operation. It seems CCS generates ECC value only using flash area.
  • 0 in reply to Zonguldak's Rose <3
    TI__Guru**** 196306 points

    Here is an example if linker file to generate ECC for the whole flash:

     

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/2330.sys_5F00_link.cmd

  • 0 in reply to QJ Wang
    TI__Guru**** 196306 points

    1. To enable the ECC generation using Linker CMD file, CCS->project property-->ARM Linker -->Linker output

     

       When Linker ECC generation is used, the "Auto ECC Generation" during program load should be unchecked: CCS->tools->On-Chip Flash->...

    2. Add palign(0) to the SECTION of the Linker CMD file:

    Since the ECC on all TMS570 devices is calculated on a 64 bit or 8 byte boundary all data and code sections which are placed in the on-chip flash should also be aligned to a 64 bit boundary. They furthermore should also end at 64 bit boundaries to ensure that the complete section will have a length of a multiple of 64 bits and is entirely be initialized. The easiest way to achieve this to use palign(8) on all output sections in the Linker Command File which will be placed in the on-chip flash.

    Zonguldak's Rose <3 said:
    Flash bank of tms570ls3137 mcu contaion 0xff value when sector is ereased and empty but tms570lc4357 mcu containt different value.

    Because it has invalid ECC value, the ECC mechanism tries to correct the flash data using the invalid the ECC value.

    Zonguldak's Rose <3 said:
    It seems CCS generates ECC value only using flash area.

    The "Auto ECC generation" during program loading only calculates ECC value of the application image. 

  • 0 in reply to QJ Wang
    Prodigy 141 points

    Did you understand my problem clearly? When did I ask for ECC calculation from linker file? I don't wanna any solution as I explained. I wanna understand this problem in detail. I won't use ECC generation from linker file. I'll use all of the flash memory with fill value (0xff).

    • There are many empty sector into the flash memory. In running time, CPU does not generate any operation on this area (Instruction or data fetch operation) but ECC must be programmed correctly even if this area is empty. When I don't use this area, why does ECC generation and calculation mechanism want  correct ECC value for my empty location. Doesn't the ECC mechanism only use my valid flash area?
    • This issue related with my configuration. I program the MCU in the same way for all 3 configuration and don't do any ECC related operation. In this case, why ESM 2.3 error count is different (per second). If it is only about Flash ECC value, MCU must recieve same ECC error number per second.
    • FreeRTOS project receives ECM 2.3 error during run time whether Flash emulation using or not. What is the different. Does FreeRTOS kernel cause any Flash ECC operation?

    Does speculative fetch operation cause all of this problem? 

    Additionally, when I close the flash region that is not used by the program code with the MPU (No Access attribute), there is no error received from ESM 2.3. If this problem releated with speculative instruction fetch operation, It seems speculative fetch operation uses random flash memory address. In this case, CPU doesn't fetch this memory area exactly because of MPU and abort signal doesn't generated because this operation is discarded. Is that true?

  • +1 in reply to Zonguldak's Rose <3
    TI__Guru**** 196306 points
    Zonguldak's Rose <3 said:
    Did you understand my problem clearly? When did I ask for ECC calculation from linker file? I don't wanna any solution as I explained. I wanna understand this problem in detail. I won't use ECC generation from linker file. I'll use all of the flash memory with fill value (0xff).

    I understood that the ECC error is caused by a speculative fetch. To prevent speculative fetch error the ECC value of the whole flash (both banks) should be programmed once.

    Zonguldak's Rose <3 said:
    Does speculative fetch operation cause all of this problem? 

    The speculative fetch will generate an un-correctable ECC error.

    If the compiler generates a compare against a register contents, and then the next instruction is an LDREQ Rd,[Rs] (conditional load). The CPU starts the memory access based on the contents of Rs, before it evaluates the results of the compare. If the compare is not equal, Rs may have some random value. The CPU discards the memory contents it read (not put into Rd) and does not do an abort. But the memory read generated the CPU event signal that tells the ESM there was an uncorrectable flash error. 

  • 0 in reply to QJ Wang
    Prodigy 141 points

    In this situation, if I set MPU as no access to unused flash region, CPU can't fetch any instruction from unused flash region. Normally, CPU generates an abort but there isn't an error because of discarding this operation. Also ESM 2.3 error doesn't recieve because CPU couldn't access even it is speculative access to random flash memory content.