.NET CF Init error

Toradex Windows CE 7.0 2.3 for Tegra Built Jul 1 2019 15:59:58
INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb
L2 cache enabled
MainMemoryEndAddress adjusted from 0x9F000000 to 0x9FE00000
Main Phys Mem: 0x80000000:0x9FDFFFFF
Carveout Phys: 0x9FE00000:0x9FFFFFFF
Cold boot selected
SMP: Active CPUs = 4
Extended Mem : 0xA0000000:0xBFFFFFFF
Chip Id: 0x30 (Handheld SOC) Major: 0x1 Minor: 0x3 SKU: 0xb0
ATE prog ver 4.0
Speedo: CPU: 327 (Corner: 1), Core: 212 (Corner: 0)
NVRM Initialized shmoo database
PllClocks(Mhz): X=1300, M=800, C=600, P=408, A=24.576
SysClocks(Mhz): CPU=1300, AVP=240, SysBus=240, Mem=400, EMem=800
GraphicClocks(Mhz): Host=133, 3D=133, 2D=133, Epp=133, Mpe=133, Vde=408

That was the output of the debug UART when we had the problem.

After flashing 2.4 it booted normally, do you want the output of that?

*Most likely, one or several files were corrupted or deleted. *

That is what we were thinking as well, but which files? Is the situation recoverable without reflashing the whole operating system? Can we check the health of the volumes if the system is new started?

The concerning aspect of this bug was the fact that this corruption happened AFTER boot. That is new for us. We had seen these CF Init errors on bootup and we are in the process of trying to secure our bootloader to try and prevent this below

Do you have RX pin of UART connected to pullup? If not than you can have an issue of registry erasing. .NET CF Initialization Error With VF61, Win EC7 and CF 3.5 - #5 by luka.tx

But that doesn’ t seem to be the problem here.

Could you please describe your system in detail, focusing on possible write operations to internal storage?

Sure. We have a custom carrier that holds one Colibri T30 IT with the 4GB of emmc storage there and the carrier board has a receptecle for a micro-SD card. We use a 16GB class 10 made by Kingston.
We write quite a few small files every minute to the SD card. And we also write a large amount of logging information to this card every 10-30 seconds. Even though we buffer this info, we are slowing seeing that this could corrupt this card.

Our image and the CF framework is installed on the emmc. We use the default toradex hive based registry. We only really write to the emmc in case we can’t write to the SD and the system is about to reboot. The rest of the writes are volumes in RAM, and those are mostly signal files that our processes are looking for. So we are kind of surprised about the emmc being corrupted. As far as we know, the amount of writes should be relatively small.

Is that enough detail? Or is there something I might have missed?