Can you please probe your SPI Data lines to see this is how the data arrives in the first place? Also, you can verify this using the UART Debug prints.
- Madhu Sudhan
Thanks for your reply. We aren't using SPI flash as a source for audio data like is done in the Cypress UAC example. We've modified the example slightly such that the audio data does NOT get sourced from flash memory.
In the Cypress UAC example it looks as if CyFxUacSpiTransfer() is used within the UAC application thread to retrieve the audio data, and then this data is copied to a buffer obtained via CyU3PDmaChannelGetBuffer(). Once the audio data has been copied then it is committed via CyU3PDmaChannelCommitBuffer().
However, in our modification instead of retrieving audio data from SPI flash and copying the data into the buffer (as is done with the example app), we just fill-in the buffer with fixed data values to represent the audio data. The idea of this was to start with fixed data buffers that would represent 48 samples of audio data, and then stream this to an Isochronous endpoint and record the data on the host PC. For the most part this works as expected. [Ultimately we're hoping to send the audio data over FX3 Slave FIFO]
The questionable part though has to do with the data itself. The recorded data on the host PC didn't seem to correspond to the values in our data buffers. For example, we were expecting that a value of 16384 (0x4000) at the FX3 would correspond to a floating-point value of 0.5 on the host PC. But this didn't seem to be the case. We found that if prior to committing the data we first right-shifted the data by 5 then the recorded values would seem to be appropriate. For example, using a value of 512 would produce a corresponding recorded value of 0.5 on the host PC. This doesn't seem right, but perhaps we're missing something obvious. Definitely appreciate your help in trying to understand what we're missing here...
Have you solved this issue? I am facing the similar problem.