-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switching the multiplexer triggers re-mount of the sd-chip on the connected PC #7
Comments
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? |
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. |
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
|
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:
Steps to reproduce expected behavior:
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?
The text was updated successfully, but these errors were encountered: