TDA3MV: ECC behavior of unaligned access to DDR3

Hi Rishabh,

thank you for your fast reply.

Regarding to the application note, with enabled cache on M4 it is not so clear that ECC will work fine.

2.5.1.3 Cached CPU Accesses to EMIF
For cached CPU access to EMIF, the accesses are typically cache line aligned. Hence, the restriction of
RMW is not applicable. However, the cache used must be “write-back, write-allocate”. Non “write-allocate”
caches might generate non-quanta aligned write accesses. Besides this, there are few more points that
need to be considered for the following CPUs.
• M4
Cortex M4 has a write allocate cache. Hence one can set cache policy to "Write back, Write Allocate"
in order to prevent sub quanta accesses to the memory. However this is not true during cache
maintenance operations:
– In IPU system, an access can result in a cache miss while maintenance operation is going on. This
can happen with either single core or both cores running. In such cases:
• Cache Read Miss will not Allocate
• Cache Write Miss will be write-through No-Allocate
– Hence, unaligned writes go through to DDR memory when a cache maintenance operation is
ongoing and ECC error interrupts are generated.
– This does not happen for normal cache eviction.
– Cache maintenance operations are: Write back, pre fetch, invalidate, lock and unlock
Below software workarounds can be used to mitigate this:
– This workaround is applicable to systems where both cores of dual core IPU subsystem are used.
The idea is to stop the other core from doing anything when the first core calls cache maintenance
API. Modify the cache wrapper APIs to follow the below sequence:
• Disable_task_scheduling
• Take_spinlock
• Disable_interrupts
• Stop_other_core
• Do cache maintenance
• Start_other_core
• Restore_interrupts
• Release_spinlock
• Restore_task_scheduling
Note that one CPU will have to be idle when the other is doing cache maintenance.

2.5.1.4 Non CPU Access of EMIF Memory
-->These restrictions are also very complex and riskfull and may not be respected in all situations.

This is a realy hard workaround and what is meant by mitigate? This workaround should work 100% otherwise it is useless to use ECC.

Please do you have answers to my primary questions, too?

Best regards,
Milan

Hi Rishabh,

thank you for your answers.

Our software use the cache on M4 and DSP side activated in the bootstrap.

Here is a list of my questions:

Q1)
From my first message: To be sure...so in the end, if an unaligned write access by the M4 without cache enabled occured, reading of this same address later generates an 1-bit or 2-bit error event and the read value is corrupted. Is it right?
I assume in case of 2-bit error the read value should be correct, cause of no possibility of correction?

Q2)
Is it realy a good idea to check and modify the whole software on all cores to avoid unaligned write accesses? I think it is more likely that an unaligned access remains undetected, than an ECC error happens. So another solution would be to use DDR3 with integrated ECC functionality. What do you thing about it?

Q3)
What about SYS/BIOS? Is it prepared for all ECC restrictions on all cores with and without cache enabled (A15, M4, DSP, EVE)? I mean also the workaround in case of cache maintenance operations and the use of both M4 cores.

Q4)
For workaround for cache maintenance operations. What is meant by: "Below software workarounds can be used to mitigate this:". Mitigate is not 100%. And what about EVE and Sys/Bios?

Best regards,
Milan