TMS570LS1114 Flash ECC Speculative Fetches

Erik Wolf

SPNU515B chapter 5.3.1 suggests that the entire ATCM space should be programmed to avoid unexpected ESM triggers.

Due to the thirdparty bootloader implementation we are using in our project it is not possible to avoid those holes. The project requires sector 1 to be not fully filled and the last 8 bytes of sector 12 to be unprogrammed.

No my question is, does this affect the ECC check relating to speculative fetches of the mcu? The bootloader is not enabling SECDED and the application which is using this feature is not accessing the section 1 memory area but may access the 8 bytes in front of the 8-byte-gap in sector 12. How does the speculative fetches work? which memory area is speculatively fetched and does it always generate an ECC uncorrectable error although the corresponding flash address are never used (writing or executing)?

Hope you are able to clarify this issue.

over 8 years ago

0 Charles Tsai over 8 years ago

TI__Guru**** 191296 points

Hi Erik,
The recommendation to fill the holes with their respective ECC values is to avoid un-correctable ECC error due to speculative fetch. If the bootloader is not enabling the SECDED then you don't need to worry about generating ECC errors as there won't be any. I think the problem is that you said your application will access some of the bytes ( 8 bytes in front of 8-byte-gap) in sector 12. Does you application enable ECC? Do you have ECC for these 8 bytes in front of the 8-byte-gap in sector 12? If the application is reading these intended addresses for which do not have their corresponding ECC and if the ECC is enabled then you will get uncorrectable ECC errors. This is not even speculative fetches. It is a direct access by the CPU.

Please also note that the speculative fetch is for instruction fetch. There is no data speculative fetch. So if your application is doing a data read from the 8 bytes in front of the 8-byte-gap then it is possible that the CPU will do a prefetch for the next 8 bytes which is your 8-byte-gap. The prefetch is different from the speculative fetch which is related to the instruction fetch though.

Another note is that if an speculative fetch is later NOT TAKEN by the CPU into its pipeline then it will not result in any data abort exception. However, the CPU will still detect it as an ECC error and the ESM flag will be set.

0 Erik Wolf over 8 years ago in reply to Charles Tsai

Prodigy 60 points

Hi Charles,

thanks for your reply.

Charles Tsai said:
Does you application enable ECC? Do you have ECC for these 8 bytes in front of the 8-byte-gap in sector 12?

Yes indeed, the application is enabling ECC detection/correction in the flash wrapper. The 8 bytes in front of the 8 bytes gap do have an ECC value due to we are using the F021 API with Auto-ECC-generation to flash the application (out of the bootloader). So, if I did understood the ECC check correctly, there is an ECC value for a whole 8-byte-block and if the application is not trying to read data from the gap there will be no ESM reported.

Does the speculative fetch only fetches the next 8-bytes from the current instruction address or does the "prefetch-boundary" vary?

We need to definitely avoid the ESM flag to be set due to this may influence the behavior of the companion chip (TPS65381).

0 Charles Tsai over 8 years ago in reply to Erik Wolf

TI__Guru**** 191296 points

Hi Erik,

If you have ECC for these 8 bytes before the 8-byte-gap then there will not be any ECC error unless it is truly an error due to flash defect. So I think you will be fine.

Is my understanding correct that these 8 bytes before the 8-byte-gap are only data and not instructions? If they are only data and the application only read from these data then you shouldn't need to be concerned with speculative fetch. As I mentioned, the speculative fetch only concerns instructiosn, not data. If these 8 bytes are instructions and the application branch to these 8 bytes of instructions then the speculative fetch can happen. As far as how and where exactly the CPU will speculatively fetch from, I don't really know. Please refer to the below ARM TRM excerpt. It depends on several factors such as branch prediction and the return stack.

5.1 About the prefetch unit
The purpose of the PFU is to:
• perform speculative fetch of instructions ahead of the DPU by predicting the
outcome of branch instructions
• format instruction data in a way that aids the DPU in efficient implementation.
The PFU fetches instructions from the memory system under the control of the DPU,
and the internal coprocessors CP14 and CP15. In ARM state the memory system can
supply up to two instructions per cycle. In Thumb state the memory system can supply
up to four instructions per cycle.
The PFU buffers up to three instruction data fetches in its FIFO. There is an additional
FIFO between the PFU and the DPU that can normally buffer up to eight instructions.
This reduces or eliminates stall cycles after a branch instruction. This increases the
performance of the processor.
Program flow prediction occurs in the PFU by:
• predicting the outcome of conditional branches using the branch predictor and,
for direct branches, calculating their destination address using the offset encoded
in the instruction
• predicting the destination of procedure returns using the return stack.
The DPU resolves the program flow predictions that the PFU makes.
The PFU fetches the instruction stream as dictated by:
• the Program Counter
• the branch predictor
• procedure returns signaled by the return stack
• exceptions including aborts and interrupts signaled by the DPU
• correction of mispredicted branches as indicated by the DPU.

0 Erik Wolf over 8 years ago in reply to Charles Tsai

Prodigy 60 points

Thanks for the detailed information to the PFU. This makes the situation much more transparent to me.

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS1114 Flash ECC Speculative Fetches