Corrupted files - TRIM command

I implemented BSP V1.6 and corresponding Microsoft updates. I sometimes observe corrupt files on the flashdisk.
If using BSP V1.6 but CEDDK.dll from BSP V1.3 I do not observe corrupt files.
A similar issue (Corrupted files after copying to Flashdisk - Technical Support - Toradex Community) suggests disabling the TRIM feature.

Question: is the TRIM function (Windows Embedded Compact - iMX6 BSP Release) located in CEDDK.dll or in another dll of the BSP? The goal is to use BSP V1.6 with an older version of CEDDK.dll but take advantage of TRIM feature.

Dear @zorro,

The TRIM command implemented in SDMEMTXDllMain.dll and doesn’t link with CEDDK.dll. However, the TRIM command implementation is really a bug, we have a plan to solve it. I believe, using v1.6 BSP and older version CEDDK.dll is not a workaround, the issue may come when you are actually using the device.

Hence, at the moment, disable the TRIM feature and use it.

Dear @zorro,

Sorry for the delay we already found the cause of the issue with the TRIM functionality and are working on a fix. I will come back next week with a test version for you.

Dear @zorro,

I’m struggling a little bit bit this fix. The problem is quite clear: when deleting a file its sectors are deleted with a special trim command to the emmc so that the emmc logic knows that those sectors contain no useful data and does not need to care about them anymore. This speeds up write operations over time as it avoids copying unneeded data. Unfortunately if we just send the trim command everytime some sectors are not needed anymore it will slow down some operations quite a lot. That’s why we queue up consecutive sector delete requests and delete them all at once.
This queuing had a little problem: if some consecutive sectors are queued for deletion (but not deleted yet) and then a write within this sector range happens before the sectors are really deleted the write will get lost, and this is the reason of data corruption.
Now, i have different solutions to solve the issue, but so far the easy ones all have the side effect to slow down normal operations as i need to force more trim operations to happen immediately.
I’m working on a delayed trim thread solution, but this is way more complex to test as it’s asynchronous to the rest of the operations, but it’s the solution that i think will solve the problem without any noticeable performance penalties.

For those enountering this, you may want to check option “TransactData”=dword:0|1