reading Micro SD Card PCB? I remembered I had an ongoing area of research - has anyone seen a solution for emulating an SD card for embedded development.
When I’m working with Zephyr, I can often flash over JLink, reboot and then monitor the console over USB. This is nice and smooth, however when working with Yocto (for example), I do a build, flash the image to an SD, move it to the target (a Pi for example), reboot and test… what would be great is if I could do something like have a device with onboard memory connected to my host device via USB, so I can drag and drop the image.bin to it as USB mass storage, then tell that device to appear like an SD card to the target device and have the magic-device connect to the target with a ribbon cable with an SD card like adapter on the end.
it doesn’t sound to difficult, in fact I think the linked question could be used as a starting point. In fact, I could probably simplify by adding some switches to the various SD lines and making it look like an SD card to my host PC… the switches being used to control which system the “SD card” is connected to. But, in cases like this, i can’t imagine my requirements are unique, so someone must have solved it. I remember seeing something on hackaday once, but for the life of me i can’t find it anymore… and a google search is not turning up much; I am finding a lot about emulating full systems - it’s one of those cases where the same search terms have other meanings that are much more common…
I had this problem when developing operating system images for One Laptop per Child, which were Linux filesystems on SD card or soldered eMMC, written to by firmware that read from a USB flash drive.
I used two methods to shorten the time between edit and test;
make the SD card available over writeable rsync, loop mount the new image on my development system, and use it to quickly update just the changes on the target,
use an editor with remote access features to edit the files on the target, then reboot the target.
This would depend on your target having network access to your development system. If it doesn’t have wireless, you could configure it as a network device.
Back in the day (1990s and early 2000s) there were similar widgets to emulate EE/P/ROM chips. I worked on several DVD players which used such an emulator. The device was basically a RAM chip(s) having the same capacity as the ROM they were emulating, and a method to load the RAM from your PC. As best I can remember, one of these used USB, and I think another used serial or the parallel port. So clearly there was a small microprocessor in charge of initializing the RAM.
These were “emulators” only in the hardware sense of the term, that is, they had no idea of the contents of memory, variable names, program flow, etc. And I suspect as hardware emulators, the emulation was superficial. I don’t think extra circuitry was in the device to emulate the slower access times, write times (in the case of flash), etc. They simply emulated the memory contents of a ROM for convenience of repeated edit-compile-debug development cycles.
With that in mind, something like I just made in the reference question, or the Voltlog eMMC project, could easily be expanded to do what you want. What’s missing is a way to simulate the eject / insert cycles of a uSD card. I think the only way to do that would involve a motor.
I’ve always liked to track the edit to test time and cycle count and invest in ways to reduce it. The payback can be considerable, which takes it from convenience to competitive necessity. The worst thing that can happen is that your code works perfectly first time and all your investment in iteration tooling seems silly.
When developing on a raspi CM4 with EMMC specifically, they have the rpiboot utility to load a specialized firmware over USB into RAM to mount the EMMC as a USB mass storage device. Perhaps that utility already supports SD instead of EMMC and that strategy could be scripted to delta-update the newly mounted partitions?
The biggest issue I see with any option is making sure the DUT is in a reset state (or off) before writing the storage. This strategy would work, though I think you MUST physically toggle the boot select pin. Perhaps there’s a software-only way to reboot-from-usb.
As for any old custom hardware situation, given the need to ensure the DUT is offline, perhaps you can employ a similar technique to make the DUT mount it’s SD card over USB programmatically.
no idea off the top of my head - what price would you put it at? I have nothing to back this up, but i feel between $10 → $20 USD and I would pay it to solve the problem. I have no idea what the BOM cost is (and haven’t looked into it either!) - but at around $10 I would buy several to have them available for the various targets I work with on a regular basis
i assume the company owns the IP or could you share?
oh damn, i completely forgot I have an eMMC CM3 (and I/O board) buried in my parts box, that might be worth pulling out as a dev target! thanks for the reminder!
I don’t mind physically rebooting the target or what have you, but the constant SD swapping and imaging was a pain. obviously as much automation as possible would be great. I can imagine this solution would be amazing for remote work as well. Imagine remote DUT connected to a Pi Gateway that you can VPN into - simple FOTA
WiFi SD cards for 3D printing. It’s a mounted file system that you can access over the network. Can’t say what the speeds will be like though.
You can mount a second SD to a Raspberry Pi, and with an extender cable plump that into the other device - once written to, unmount and boot the board that needs the data - at least I think this will work.
I have nothing to back this up, but i feel between $10 → $20 USD and I would pay it to solve the problem. I have no idea what the BOM cost is (and haven’t looked into it either!) - but at around $10 I would buy several to have them available for the various targets I work with on a regular basis