Switching the multiplexer triggers re-mount of the sd-chip on the connected PC

[readahead1]

The ESP32 chip runs a firmware which is switching the multiplex between the SD-slot and ESP32 chip. After the multiplexer is switched to ESP32 for more than 400 ms and then switched back to the SD-slot, the PC which is connected to Uploader & card reader board via USB remounts the chip. The same doesn't happen if the SD WIFI PRO is inserted into a plain UHS-I sd card reader from another vendor.

Steps to reproduce unexpected behavior:

1. flash a sample firmware to SD WIFI PRO which switches the sd chip via IO26 to the ESP32 and mounts and unmounts it periodically
2. Insert SD WIFI PRO into the Uploader & Card Reader Board and connect it via USB to a PC
3. Every time the sd-chip is return to the Uploaded & Card Reader board, the PC re-mounts the sd-chip

Steps to reproduce expected behavior:

1. flash a sample firmware to SD WIFI PRO which switches the sd chip via IO26 to the ESP32 and mounts and unmounts it periodically (same)
2. Insert the SD card into a plain UHS-I reader from another vendor
3. No re-mounts of the sd-chip on the PC is triggered while the PC is in idle

Already tries:
I realized that there are no 10k pull-up resistors on the GL823k chip if the multiplexer is in NO/ESP32. Added these 10 k pull-up resistors via the headers of the Uploader & Card Reader Board but it did not help.

Could you please advise what resistor/ capacity should I add to the headers of the Uploader & Card Reader Board in order to avoid this problem?

[eliwong]

You mean

When you use the Uploader & card reader board to switch the storage chip from ESP32 to GL823K, the PC will remount the device. But it won't when using other card readers. Is that right?

I think this may have something to do with the way GL823K works. Some card readers will display the drive letter when there is no SD card, while others will not.

As for the 10K resistor you mentioned, GL823K does not have this resistor. Am I missing something?
The GL823 specification may help you:
Genesys-GL823K.pdf

[readahead1]

According to my recent test, most of the card readers (other than gl823k) initiate a power cycle as recovery if they the sd chip is not responding because the ESP32 is using that. This is seamless for the host but ESP32 needs to deal with the unexpected restart. Overall it is an optimal behavior.

The re-mount is probably GL823k specific. I tried to add 10k pull-up resistors but it didn't help. I have also read on sdcard.org that pull-up resistors should be part of the host and not part of the card. As I am only using gl823k for programming, this issue is obsolete.

I have a 3d printer with card reader which displays sd card error and doesn't do any auto-recovery (no re-mount, no power cycle). For that case the ESP32 should trigger recover via power cycle or via CMD0 reset because otherwise only manual re-insert helps. I open a separate issue for that.

[tiredboffin]

According to my recent test, most of the card readers (other than gl823k) initiate a power cycle as recovery if they the sd chip is not responding because the ESP32 is using that. This is seamless for the host but ESP32 needs to deal with the unexpected restart. Overall it is an optimal behavior.

1. It perhaps is not that unique in this regard - in the following two readers SD WifI Pro also does not reboot when ESP32 takes control over SD chip even for minutes-- time enough to upload/download about 1G file over wifi .

The card stays mounted on PC side and if the host tries to read from the card (I used dd if=/dev/sdc1 in my test) at the time of the transfer i.e. when the SD is under ESP32 control, the kernel reports the following I/O errors:

2. The reader board when used as SD card reader though reports "capacity change" to PC in about a second after ESP32 takes the control.

and udisksd tries to re-read partition table, fails and cleans up the mount point.

It reports "capacity change" again when ESP32 relinquishes the control and and udisksd mounts the card as if it was physically re-inserted:

3. In the following generic noname reader SD Wifi Pro card does reboot as you described:

The reader first reports "capacity change to 0" (similar to the board case (2) above) followed by immediate "capacity change from 0"

This is the least desired behaviour for my use case.

[readahead1]

According to my recent test, most of the card readers (other than gl823k) initiate a power cycle as recovery if they the sd chip is not responding because the ESP32 is using that. This is seamless for the host but ESP32 needs to deal with the unexpected restart. Overall it is an optimal behavior.

1. It perhaps is not that unique in this regard - in the following two readers SD WifI Pro also does not reboot when ESP32 takes control over SD chip even for minutes-- time enough to upload/download about 1G file over wifi .

The card stays mounted on PC side and if the host tries to read from the card (I used dd if=/dev/sdc1 in my test) at the time of the transfer i.e. when the SD is under ESP32 control, the kernel reports the following I/O errors:

2. The reader board when used as SD card reader though reports "capacity change" to PC in about a second after ESP32 takes the control.

and udisksd tries to re-read partition table, fails and cleans up the mount point.

It reports "capacity change" again when ESP32 relinquishes the control and and udisksd mounts the card as if it was physically re-inserted:

3. In the following generic noname reader SD Wifi Pro card does reboot as you described:

The reader first reports "capacity change to 0" (similar to the board case (2) above) followed by immediate "capacity change from 0"

This is the least desired behaviour for my use case.

This is a great overview thank you!

In the 1st case when kernel reports the I/O errors and neither reboot nor re-mount happens:
does the communication between card and PC auto-recovers after the ESP32 is not using the sd-chip anymore? In my case when I/O error occurs, then I need to manually re-insert the card...

[tiredboffin]

This is a great overview thank you!

In the 1st case when kernel reports the I/O errors and neither reboot nor re-mount happens: does the communication between card and PC auto-recovers after the ESP32 is not using the sd-chip anymore? In my case when I/O error occurs, then I need to manually re-insert the card...

I modified my ESP32 code to log the reboots properly and now from the logs I can see that in case (1) above ESP32 does reboot after all. My initial analysis for the case (1) was wrong as dd uses read cache by default and in my quick experiment it did not trigger a collision as it was reading from the cache. Sorry for the confusion. I have disabled the cache and can confirm that if there is a collision then both readers in (1) reboot the card silently. On the host side these collisions/reboots may get completely unnoticed (as my ESP32 code relinquishes the control first thing in setup()) or occasionally I observe I/O errors in the host logs. If the host does not use the card or it hits the cache at the time SD is used by ESP32 then SD card stays mounted, ESP32 is not rebooted, I see no errors in the host logs -- no collision no problem.

Case (3) is still a bit different as the reader unconditionally reboots ESP32 about a second or two after ESP32 takes the control -- when the card is not used by the host and is not even mounted on the host side. This reader is more problematic compared to case (1). I can only guess but from above it seems that

• case (1) readers rely on Card detection switch for card presence
• case (3) reader uses polling to detect the card presence -- perhaps it does not even have the detection switch - it does not "click" when I am inserting the card.
• case (2) dev board GL823K is perhaps configured (or hardcoded) to use the switch to connect USB and to use polling to detect the card presence. From schematic I think it does not have control over power line to reboot ESP32 --even if it tries to -- otherwise the board would behave as case (3) reader and would be unusable.