• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 597 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.

Original question:

TMS570LC4357: L2FMC#5 with the flash prefetch disabled part of the time

TMS570LC4357: L2FMC#5: safe by default?

1138
Expert 1226 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

We are analyzing our vulnerability to the following errata for the TMS570LC4357 MCU:

L2FMC#5 Incorrect data read from flash ECC data memory region, flash OTP memory region, or data flash memory region when configured as "normal" type memory

I appreciate that there is a suggested workaround by using the MPU to configure memory as either "device" or as "strongly ordered" regions.  This is not easy for us to do, as we are already making heavy use of our MPU regions to provide isolation for safety-critical code; in fact, we're already in the position of needing to make undesired compromises in the allocations of our MPU regions as it is.

However, it may be that our current usage is already safe from this by default?

My understanding is that an ARM CPU using the ARMv7-R architecture (which I believe includes the TMS570LC4357's ARM Cortex-R5F, correct?) has the memory region of 0xC000:0000 - 0xFFFF:FFFF set as strongly ordered by default.

Since the "Flash ECC, OTP and EEPROM accesses" are listed as being in the range from 0xF000:0000 - 0xF047:FFFF, my understanding is that as long as we _don't_ create an MPU region that encompasses some or all of the 0xF000:0000 - 0xF047:FFFF range, that we are in good shape; is this correct?

Is it relevant that we _do_ have MPU regions covering the normal flash range of 0x0000:0000 - 0x003F:FFFF, and that we are _not_ setting those addresses to be strongly ordered?

--thx

  • 0
    TI__Mastermind 49120 points

    Hello,

    The "default memory map" you are referencing is only applicable if the MPU is not enabled. Once you enable the MPU, the memory regions to be accessed within the 4GB space must fall within a defined region.

    Typical applications do not have to read very frequently from the flash ECC memory or the flash OTP region, so it is only a question of configuring the data flash memory (the 128KB bank) as device type or strongly-ordered.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1226 points

    Hello Sunil,

    We have the MPU background region enabled. My understanding is that if the background region is enabled then the default memory map applies, as long as the CPU is in privileged mode.  And that the TMS570LC4357's default memory map already has the desired settings for the flash areas.  Correct?

    We use HALCoGen's FEE functions (and, by extension, the F021 library) to access the TMS570LC4357's "128KB of Data Flash for Emulated EEPROM With ECC".  We call the FEE functions with the CPU in privileged mode, because of their usage of flash control registers that can only be accessed in privileged mode.

    As such, there would be no need (or any benefit) for us to use any MPU regions to cover the issue described in L2FMC#5, correct?

    --thx

  • 0 in reply to 1138
    TI__Mastermind 49120 points

    Hello,

    We have the MPU background region enabled. My understanding is that if the background region is enabled then the default memory map applies, as long as the CPU is in privileged mode.  And that the TMS570LC4357's default memory map already has the desired settings for the flash areas.  Correct?

    >> Region 0 usually covers the entire 4GB addressable CPU memory region, and defines the access permissions for the "background" region. This region as defined by HALCoGen could be different from the default settings described in the Cortex R5 TRM.

    We use HALCoGen's FEE functions (and, by extension, the F021 library) to access the TMS570LC4357's "128KB of Data Flash for Emulated EEPROM With ECC".  We call the FEE functions with the CPU in privileged mode, because of their usage of flash control registers that can only be accessed in privileged mode.

    >> You don't need to use an API function to read from any Flash memory. The L2FMC#5 issue only applies on read accesses.

    As such, there would be no need (or any benefit) for us to use any MPU regions to cover the issue described in L2FMC#5, correct?

    >> If you do have frequent accesses to the data flash memory (most likely) or to any of the ECC regions or the OTP regions, then these memory ranges must be configured as "device" type or as "strongly ordered" type.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    TI__Mastermind 49120 points

    You rejected the previous answer without an explanation. Is there anything unclear about the comments in my post?

  • 0 in reply to Sunil Oak
    Expert 1226 points

    Hello Sunil,

    Thank you for following up!  While your comments were certainly relevant, they did not answer the core of our question.

    Our question is specifically about the background region.  We are not defining any MPU memory regions (neither region 0 nor any other MPU regions) which cover the data flash area used by the FEE code.

    However, having dug through the ARM technical documentation, it is our working understanding that this is not a problem, because we have the MPU background region enabled, and that seems to already provide the correct settings the errata is specifying to use for the data flash area (as long as we only access the data flash while in privileged mode).

    However, we are not experts in this area, and even if we were, the information we're looking at is in ARM's documentation, not TI's documentation, and for all we know could be misleading us because of some kind of TI-specific detail.

    We are hoping that you can confirm that our understanding about how the background region works is correct.  (Note that we are already using all of our MPU regions to provide access protection to various safety-related RAM data and MCU peripherals, so the prospect of needing to compromise this in order to squeeze in another MPU section for our FEE usage is not an easy one.)

    --thx

  • 0 in reply to 1138
    TI__Mastermind 49120 points

    Hello,

    Yes, you can use the "strongly ordered" memory type defined by the "default memory map" for any memory location between 0xF0000000 and 0xFFFFFFFF that is not part of a defined MPU memory region. For this the bit 17 of the system control register must be set while also enabling the MPU (this bit is 0 by default, which would cause a background fault and an abort exception on any access to this region).

    Please note that this will use the memory type defined in the default memory map for all locations that do not fall in a defined memory region.

    Regards, Sunil