I have inherited some firmware code for our CX3 chip, which is connected to an OV4689 sensor and streaming video over USB 3 to the PC. The person who wrote the firmware code originally needed to send/receive (3K worth of) camera calibration data over USB, and couldn't figure out how to do that. So, they created separate dma channels to send and to receive "side-band data" to/from the PC. I don't understand this code very well. I would have thought ONE dmachannel, bi-directional, would be enough, but this person created two...
The way it's supposed to work is by handshake. The PC sends a request to the firmware, the firmware processes the request, and sends a reply. The firmware never issues a DMA request to the PC first. This should make it straight-forward.
When the PC sends a request to the CX3, I get notified in the DMA callback. For whatever reason, the programmer wrote it so there is a background, application thread, and when the callback gets called that a DMA buffer was received, an event is set, and the background thread goes and reads the event and does what is necessary (like send calibration data).
The DMA "produced" callback calls DMAChannelGetBuffer( RecvStream ), then reads the packet, then calls DmaChannelDiscardBuffer( ), then sets the event for the background thread. The background thread then calls DmaChannelGetBuffer ( SendStream ), copies the calibration data, then calls DmaChannelCommitBuffer( ).
On the PC side, I've opened up an overlapped IO file handle and am sitting there waiting for reads from the sideband USB channel. No rocket science there.
NOW WHAT IS WEIRD:
If anywhere in the background thread, I call CyU3PThreadSleep(), even with a timeout of just 1, the DMA transfer won't happen. DmaChannelGetBuffer( SendStream ) will sit there and time out! A timeout would seem to imply the send buffer is "busy", but since this is the first packet I'm sending over DMA, I don't see how it could be busy. There is something else weird at work here.
Anybody have any good advice, thoughts?