There is a problem with the XVC protocol is written.
Normally the TMS vector needed is a lot shorter to get a device into programming mode while the bulk of the programming data is handled in the TDI/TDO. The protocol expect that both the TMS and TDI vectors are output to the device while receiving the TDI in one go. While this provides the maximum flexibility, it is the part that causes a bottleneck on the performance.
I though using the SPI would have improved the situation, but I guess I didn't read the fine prints carefully to realize that I need to have both outputs.
I am in the process of working on my new design using a popular cheap but capable STM32F103. It is the same size as the ESP8266 module and consumes a lot less power.
3D model |
Top side |
Solder side |
SPI1 and SPI2 are used to drive the JTAG signals |
ST wired the SPI2 to the AHB1 clock domain (36MHz) which limits the overall data rate to 18Mbps instead of the 36Mbps supported by SPI1. The bottleneck in this design is Full Speed USB (12Mbps).
My bare metal (i.e. no libraries) SPI DMA + interrupt code works on first try! It is probably a lot easier (for me) than baby sitting the 3 SPI data stream and keeping them well fed with firmware loop. It also frees up the CPU for the rest of the code.
The SPI is set up for 8-bit transfers using 3 DMA channels for each of the vectors. A bitbang routine handles any left over bits. It is hooked to the DMA completion IRQ and takes 3us for the switch over. The bitbanging is at 1.8Mbps which is 1/10 speed of SPI, but it only need to deal with at most 7 bits of data.
The next hard part is dealing with Windows, USB and the networking stuff.