SD Card intermittently not recognized after reboot (CC100)

Hardware and Linux
,
1

Hi everyone,

I’m facing a recurring issue with the WAGO CC100 Edge Controller related to SD card detection after rebooting the system.

Setup & steps taken:

  • Controller: WAGO CC100
  • SD card formatted using the Web-Based Management (WBM) interface:
    WBM > Mass Storage > Create New Filesystem on Memory Card
  • Initially, the SD card is recognized correctly, full capacity is shown – everything seems fine.
  • df -h displays the SD card as expected
  • fdisk -ul also shows the correct layout

Issue: After rebooting the controller (reboot), the SD card is intermittently not recognized correctly.
Roughly 50% of the time, it doesn’t show up after boot.

dmesg | grep mmc output shows:

[    0.998435] mmc0: new SD card at address d555
[    1.004944] mmcblk0: mmc0:d555 SD032 30.6 MiB

→ It identifies the card, but only as 30.6 MiB, even though it’s a 32GB card.

df -h output shows:

Filesystem                Size      Used Available Use% Mounted on
/dev/root               581.4M    187.8M    351.1M  35% /
devtmpfs                246.6M     12.0K    246.6M   0% /dev
none                    247.1M      8.0K    247.1M   0% /tmp
none                    247.1M    156.0K    247.0M   0% /media
none                      4.0M    124.0K      3.9M   3% /var/log
none                    247.1M    136.0K    247.0M   0% /var/run
none                    247.1M         0    247.1M   0% /var/lock
none                    247.1M         0    247.1M   0% /var/tmp
none                    247.1M         0    247.1M   0% /sys/fs/cgroup
tmpfs                   247.1M    168.0K    246.9M   0% /run
/dev/mmcblk1p2           16.0M    644.0K     15.3M   4% /boot/loader
/dev/mmcblk1p6            1.1G    184.4M    851.4M  18% /home
/dev/mmcblk1p4            6.7M     45.0K      6.1M   1% /settings
/dev/mmcblk1p3            6.7M     45.0K      6.1M   1% /log
none                    247.1M    136.0K    247.0M   0% /var/run/netns
none                    247.1M    156.0K    247.0M   0% /media/sd/docker

where /media/sd/docker usually should be mounted on /dev/mmcblk0p1.

Also, fdisk -ul output shows:

Disk /dev/mmcblk0: 30 MB, 32096256 bytes, 62688 sectors
979 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/mmcblk0 doesn't contain a valid partition table
Disk /dev/mmcblk1: 3728 MB, 3909091328 bytes, 7634944 sectors
473 cylinders, 256 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk1p1    0,0,2       1023,255,63          1    7634943    7634943 3727M ee EFI GPT
Partition 1 has different physical/logical end:
     phys=(1023,255,63) logical=(473,101,37)

where I can find that Disk /dev/mmcblk0 has issues with the partition table – issues that may have been caused during formatting via the WBM or the corresponding command:
/etc/config-tools/format_medium device=mmcblk0 volume-name=docker-sd fs-type=ext4?

Technical insight – format_medium script behavior:
During formatting via the WBM or using the manual command
/etc/config-tools/format_medium device=mmcblk0 volume-name=docker-sd fs-type=ext4,
the script internally uses the following line to partition the device:

echo ",,${part_type},," | flock "$deviceName" sfdisk -f "$deviceName" > /dev/null 2>&1

Here’s what this does:

  • sfdisk is used to write a new partition table to the device.
  • ",,${part_type},," tells sfdisk to:
    • create one partition using the entire available space (no start or end sector specified),
    • with the partition type determined by the selected filesystem:
      • "83" for ext4
      • "b" for FAT32
  • flock ensures that no other process is accessing the device during this operation.
  • This partitioning step happens after deleting any existing GPT or MBR, and before formatting with mkfs.

This reinforces my suspicion that the issue may not lie in how the partition is created, but rather in how the system (CC100) picks it up during or after boot – especially given that GParted consistently shows everything as expected.

What I’ve tried so far:

  • Multiple CC100 controllers
  • Multiple SD cards (different delivery batches)
  • Same issue: the card is either detected correctly or not – it’s inconsistent

Additionally: I’ve already tried the suggestions from this community thread, which mainly focuses on issues with the Docker daemon startup, related to the “delayed” SD card recognition:

  • Set timeout=20 (instead of 10) in /usr/local/bin/wago-automount
  • Added sleep 180 in /etc/init.d/dockerd

Unfortunately, this hasn’t helped – the issue persists.

Extra observation:
When I take an SD card that was not recognized properly by the CC100 (or shows only 30.6 MiB and no partition), and plug it into another system and check it with GParted, I can see the full capacity (32 GB). The partition is there, and it’s properly formatted as ext4 – everything looks normal from an external system’s perspective.

Important note:
We are not using the official WAGO-branded SD card.
However, we have now provisioned over 300 CC100 controllers with the same 32 GB micro SD cards and identical setup / identical setup procedure, and this issue has only started appearing this week.

My questions:

  1. Why would the SD card sometimes be detected as only 30.6 MiB?
  2. Any way to make the mount process more reliable during boot? We are using FW Version 04.01.10(23) - could this issue be fixed using a more recent FW Version?
  3. Any tricks for formatting or automounting that might help?

Any help or insights would be greatly appreciated!

Best regards

2

Hello
Can you confirm the SD card is a high quality model (SanDisk for example). Some lower quality cards have been found to have quality issues.
Curious, have you tried smaller cards, 16GB, 8GB etc?

1 Like
3

Hi @WagoKurt, thanks for the reply.

Yes, I can confirm that. We use SanDisk cards purchased from a trusted retail shop. We still have some 16 GB cards (also SanDisk) lying around, and I’ll run another test with those tomorrow to see if things work better with them. I’d be surprised if that made a difference, since we’ve never had issues with the 32 GB version during many other provisioning processes — but I’ll give it a try just to be sure. I’ll share some feedback on that during the course of tomorrow.

My second approach would be to give the latest firmware (version 28) a try, in case the test with the 16 GB cards doesn’t help either. But if you have any further input, checks, or logs for me to look into, I’ll be more than happy to follow up on them.

4

Hello, I think there is a problem when something is trying to use the SD card before it is mounted and so it create the folder SD instead of waiting for the link to be there.
For myself I’ve made a symlink in the codesys folder:
ln -s /media/sd/ /home/codesys/PlcLogic/sd
if the SD card is not there the link will be broken and the process trying to use the SD card will return an error or will wait.

Maybe creating an equivalent link somewhere and use this instead of the media/sd will work better ?
Just a suggestion. I haven’t tested this solution for your current problem.

2 Likes
5

@WagoKurt, today we tested another batch of SD cards. Also SanDisk, but this particular batch has been lying around here for a while. Interestingly, the setup worked reliably again with these cards – both 16 GB and 32 GB versions :partying_face:. The CC100 correctly detects the partitions, even after reboots. What exactly is different about the non-working cards (aside from the production batch) still remains a mystery to me – especially since they’re recognized just fine on other Linux systems (e.g., via GParted), just not on the CC100 :thinking:.

I’ll still give it a shot and see if I can get the currently problematic 32 GB cards to work with the newer FW version 28. I’ll probably be able to share some feedback on that next week. However, I suspect the root cause might indeed be related to those cards from that specific delivery batch. We’ve already ordered new ones and will test those as well.

@WagoIcard thanks for the hint regarding the symlink approach – I wouldn’t have thought of that myself so quickly. Definitely something worth trying. That said, I’m still unsure whether it would truly help in our specific case. We’re using /media/sd explicitly in combination with /etc/docker/daemon.json to offload Docker onto the SD card. Since our use case relies heavily on Docker environments, it’s critical that the containers start reliably. If implementing a custom retry/check mechanism is required merely to verify storage availability, the symlink may not effectively address the issue for the Docker daemon, as it depends directly on that mount point — and the symlink would simply be an additional layer which, in this case, would add more overhead than value. Still, I’ll definitely keep the idea in mind for other use cases – using a symlink could make a lot of sense when handling things directly within the (Docker) applications that require the file system.

1 Like
6

We received our new batch of SD cards today (both 32 GB and 16 GB) and immediately ran some additional setup tests. Interestingly, the issues we were experiencing no longer occur with the new cards.

Additionally, we ran one more test last Friday using FW version 28 and the older, problematic cards – unfortunately without success. It really seems like the issue was tied to that specific batch of SD cards, even though we still can’t quite explain what the root cause was.

Since everything is now working smoothly again, I’ll go ahead and mark this thread as resolved, as the problem appears to be less related to the CC100 itself and more to the SD cards.

Thanks to everyone who contributed and shared their insights!

7

Hello, if you can it would be interesting to see if the cad have some bad memory block which make its controller take longer time to enable it and put it online.

1 Like
8

It would be interesting to see if the SD cards you have support S.M.A.R.T feature

1 Like
9

Indeed, but can we do this in the PLC (Like PFC200 or PFC300 ?)

10

I analyzed the SD cards using my Ubuntu machine and the “Disks” tool. Everything looks fine — no irregularities, errors, or damaged blocks were found.
I also ran the two tools h2testw and Validrive on my Windows machine, again without any issues or warnings. Do you know / recommend other specific tools to check the blocks?

11

Unfortunately I wasn’t able to get the S.M.A.R.T. tool to run. On the CC100 I’m getting errors indicating that FUSE is missing.

Is it even possible to use the sbdm-cli binary directly on the CC100, or would I need to run it in a Docker container that includes the necessary libraries? I couldn’t get it running on other distros either (like Ubuntu) — though I assume it was designed specifically for WAGO devices?

Here’s what I tried:

curl -k -o sbdm-cli https://raw.githubusercontent.com/quenorha/sbdm-cli/refs/heads/main/sbdm-cli && chmod +x sbdm-cli
./sbdm-cli

Result:

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information

Running it with the additional parameter --appimage-extract-and-run will result in:

./sbdm-cli --appimage-extract-and-run
Swissbit Device Manager 1.2.4

Please wait while SBDM is scanning for devices...
libusb usb_find_busses failed: has usb_init() been called?
No supported disks found!

Any ideas or suggestions?

12

This is weird, it does work on my CC100.

Which CC100 is it ?
Which Firmware version are you running ?

I used the latest, FW28.

Note that Swissbit also provide a S.M.A.R.T tool for Windows :

13

We used a CC100 751-9301 with FW version 04.01.10(23). That version is already a bit outdated, so I’ve now also tried it with FW28 (the latest available firmware).

I’m getting the following output when running ./sbdm-cli:

Swissbit Device Manager 1.2.4

Please wait while SBDM is scanning for devices...
libusb usb_find_busses failed: has usb_init() been called?
No supported disks found!

So, the FUSE error is gone — but the SD card (a standard SanDisk card) doesn’t seem to be detected, or maybe it’s just being marked as unsupported by the tool?

Since I used an SD card from the new delivery batch, it currently seems to be recognized again – at least it shows up with df -h.

Filesystem                Size      Used Available Use% Mounted on
/dev/root               581.0M    344.1M    194.4M  64% /
[... omitted]
/dev/mmcblk0p1           29.1G     24.0K     27.6G   0% /media/docker-sd

My assumption is that the SD cards might simply not support S.M.A.R.T., but I’m wondering if the issue could also be related to usb_init() not being triggered correctly?