[Cryptech Tech] USB interface

[Peter Stuge]

Rob Austein wrote:
> But the question is whether we have time to do this, starting from
> where we are now.

Right. To be clear: I am not at zero with a SAMD11 firmware now

My current SAMD11 firmware sends a correct GET_VERSION request, but
only manages to receive a few of the bytes coming back. I see on the
scope that both request and response are correct on the wire.

The firmware misses some bytes because the FIFO is only 1 byte and
because it isn't using DMA, so it only has time for some 50 instructions
before the next byte arrives, and that's apparently not enough.

In a different project (architectural lighting) I've written a SAMD11
firmware that reliably receives UART communication without DMA, just
interrupts, but that runs at 250kbps, about 1/4 of 921kbps on the Alpha.


So, if we reduce the STM32 UART baudrate to 115k or 230k then I could
already demonstrate a working firmware.

Also, if CTS+RTS were connected then it would also already work, even
if not (yet) at maximum throughput.

While the solution in SAMD11 is definitely to use DMA, adding CTS+RTS to
the STM32 UART interface is actually a very important change anyway.

It is required to allow feedback from STM32 UART processing to bubble all
the way back to the PC. These two signals are currently all that's missing.
I wish I would have thought about that in rev3.


I suggest:

1. Move forward with SAMD11 replacing FTDI
2. Add CTS+RTS to the UART interface
3. If time and space on the board allows it, also connect SPI

Who does the hardware design changes? To support that effort I can
contribute the required connections on the SAMD11 side.

So far I've used the SAMD11 in the SO-14 package for this, but I can
provide the pinout also for the QFN24 if that is preferd?


//Peter