[Hardware feature request] Reset GPIO/output

[Manawyrm]

trafficstars

Hi,

I'm very happy with my USB-SD-Mux, thanks for making & selling it! There are 2 things I'd be happy to see in a newer revision of the hardware:

• USB-C connector
• Reset GPIO / Open-Collector output

Being able to keep the DUT in reset would be sufficient for most of my applications and would save me from having to deal with controlling an external power supply or having to try and use a different USB-converter just for the reset line.

I might just hack my board to use an unused GPIO with an N-channel MOSFET to provide this functionality, but a clean solution would be preferred :)

Thanks!

[SmithChart]

Hey @Manawyrm ,

thanks for the feedback. We are actually currently working on a new design. This design is mostly about improving the bandwidth of the system to support faster (SD104) SD-Cards. USB-C is already in the requirements and in the design. Micro-USB-B is really outdated by now :-)

Regarding the additional GPIO: We are still discussing if this is a feature we want to implement. So it's totally the right moment for your feedback! Would a signal with an Open Collector + Pull-Up be enough for your use case? Or would you prefer some isolated output? We would probably make the level of this pin available in the python tool.

For the old design we don't have any spare GPIOs, that you could use for your reset. But: If you do not mind soldering some wires to your USB-SD-Mux this may help. We have got the signal driving the DUT-LED available as active low and active high:

• The signal DUT_ENABLE is high when the DUT is selected (pulled high with 10k) and is low, when the DUT is not selected (driven by a logic gate). So this signal should work for your reset.
• The signal driving the DUT-LED is DUT_ENABLE inverted - and driven with a fairly beefy MOSFET (ON-semi FDC6401 (https://www.onsemi.com/pdf/datasheet/fdc6401n-d.pdf )

Voltage levels for both signals are 0V / 3.3V.

Best place to attach the DUT-LED signal is directly at the MOSFET:

The DUT-ENABLE signal is a little more distributed:

Does this help for now?

[Manawyrm]

Hello @SmithChart ,

wow, thanks for the detailed feedback. Yeah, that already helps a lot.

Would a signal with an Open Collector + Pull-Up be enough for your use case?

Yes, I would just attach it to the JTAG_RST/RUN/etc. line of my DUT. It's at the same ground potential as the USB-SD-Mux anyway (through the microSD slot) and I could just run a dupont jumper wire over to the 2.54mm header on my board(s).

In a redesign, some sort of current-limiting resistor (100 Ohm?) might be a good idea. That way, even if the user tries to "reset" a power supply rail, a max of 50mA will get dissipated and nothing bad happens.

Looking forward to the new revision! Please ping me if you happen to remember, I'd like to buy one :)

Thanks!

[SmithChart]

In a redesign, some sort of current-limiting resistor (100 Ohm?) might be a good idea. That way, even if the user tries to "reset" a power supply rail, a max of 50mA will get dissipated and nothing bad happens.

Yes, that will be something like this. And a Pull-Up would be so high impedance that any connection to, e.g. 12V would not damage the USB-SD-Mux.

Looking forward to the new revision! Please ping me if you happen to remember, I'd like to buy one :)

Thanks for you input! We will let you know once they are ready!

[mjk-gh]

Hey @Manawyrm ,

thanks for the feedback. We are actually currently working on a new design. This design is mostly about improving the bandwidth of the system to support faster (SD104) SD-Cards. USB-C is already in the requirements and in the design. Micro-USB-B is really outdated by now :-)

Regarding the additional GPIO: We are still discussing if this is a feature we want to implement. So it's totally the right moment for your feedback! [...]

Discussing? Oh no, please don't be like these guys:

https://www.youtube.com/watch?v=oW9_GqShJPg

;-)

Just grab one of these:

• NXP PCA9536DP,118 (doesn't allow other I²C slaves, though, don't know if that could cause problems)
• MaxLinear XRA1200PIG16TR-F

a terminal header strip, and maybe at least one of these:

• LiteOn LTV-847S

and another terminal header strip for the optocoupler outputs.

Additionally, for issue #46, place a 2-row terminal strip (populated with jumpers) for these signals

• Select
• DAT_ENABLE
• VCC_ENABLE
• Vcc
• GND
• DUT-Mode LED (not sure if this one makes sense, if you use GPIO expanders anyway)

If you design it like this, then ....

😊️

[mjk-gh]

Hey @Manawyrm ,

thanks for the feedback. We are actually currently working on a new design. [...]

Is there an ETA for the new version?

We recently acquired one with the current design; alas, for a location that does not need the GPIO functionality. But as my location does need that functionality, it might make more sense to buy a more "GPIO-friendly" version.

[SmithChart]

Hey @Manawyrm , thanks for the feedback. We are actually currently working on a new design. [...]

Is there an ETA for the new version?

We have the first generation of prototypes on our desks. Testing looks good. Next step is EMI compliance testing and production. If that goes well I expect the first batch to be available in spring 2024.

[SmithChart]

Just grab one of these:

* [NXP PCA9536DP,118](https://www.mouser.de/datasheet/2/302/PCA9536-3139488.pdf) (doesn't allow other I²C slaves, though, don't know if that could cause problems)

* [MaxLinear XRA1200PIG16TR-F](https://www.mouser.de/datasheet/2/146/xra1200_100_092011-1856036.pdf)

We have chose a TI TCA6408ARSVR :-)

a terminal header strip, and maybe at least one of these:

* [LiteOn LTV-847S](https://www.mouser.de/datasheet/2/239/LTV-8X7_series_201610_-1544776.pdf)

Our go-to part is the CPC1008N: https://www.mouser.de/ProductDetail/IXYS-Integrated-Circuits/CPC1008N But for the USB-SD-Mux we have only placed an open-drain N-MOSFET: ON-Semi NTGD3148N

and another terminal header strip for the optocoupler outputs.

Additionally, for issue #46, place a 2-row terminal strip (populated with jumpers) for these signals

* Select

* DAT_ENABLE

* VCC_ENABLE

* Vcc

* GND

* DUT-Mode LED (not sure if this one makes sense, if you use GPIO expanders anyway)

If you design it like this, then ....

This is not a use case we really want to support. But: We made sure you can still override the I2C GPIO-IC (if you never initialize it with our software). And all these signals have test points.

[mjk-gh]

Thanks for the GPIOs and the test points!

[SmithChart]

Short update on the "FAST" version: EMC-testing has been successful on the first try. Order has been placed with the manufacturer. We are now waiting on the delivery date.

[SmithChart]

The USB-SD-Mux FAST is now available: https://www.linux-automation.com/en/products/usb-sd-mux-fast.html

It has two potent open drain output, that you can use to drive external signals. They are intended to switch logic level signals (e.g. RESET or Card Detect) but the MOSETs should be capable enough for other applications, too. They are controlled using the standard USB-SD-Mux tool.

Closing this for now. Feel free to open again, if there are any questions.

[Manawyrm]

The USB-SD-Mux FAST is now available: https://www.linux-automation.com/en/products/usb-sd-mux-fast.html

Excellent! Not sure how I missed this info last month, but I was very happy to receive this parcel from my old home town 😄

Look forward to using it soon.