I wrote tech support two days ago and got no answers, so hopefully someone else has run into this and can help me.
First problem is the firmware appears to have some kind of problem I can't track down. Unfortunately I don't have any decent debugging tools, but the board I'm working with has 4 LEDs connected to port E. We didn't have the money to buy the Keil compiler in the budget, so I am using SDCC. The framework is essentially the same as the Keil/Cypress framework with some tweaks for the different syntax in the SDCC compiler.
Sometimes I download the firmware to the target and it works fine. Other times I make a minor change to the firmware, download it, and it doesn't work. The change can be something very benign. It appears to be sensitive to where the code is in memory. Moving one byte one way or the other can kill it. Adding more code might make it work again.
I set up a counter in the TF_Poll() function that caused the 4 LEDs to count up. When a version of the firmware doesn't work, the LEDs continue counting, so it appears the firmware process loop is running fine, the problem is in the connection to the host. For some reason the firmware is dropping it.
Has anybody run into this sort of thing before and if so, how do you solve it?
The second problem has to do with an ISO IN endpoint. The data load passing through the USB is very low, but we have had some speed issues. I first tried doing all I/O on the control endpoint. When I got far enough along to see through put timing, I was seeing 4ms per transaction, which is way too slow. We can tolerate a couple of microframe delay (~250us), but 4ms is way too long.
I was away from this part of the project for a few months. (Another area was demanding my attention.) Back in April when I was talking to tech support about this, they recommended I change the OUT to a Bulk endpoint and the IN to Isochronous endpoint. I already was using a Bulk endpoint for some OUT data, so it was fairly easy to get all data out on the Bulk endpoint. I analyzed the CyStream example and set up an ISO IN endpoint. I figured out a way to do all input with one ISO IN.
Unfortunately, the ISO IN endpoint was very unreliable. When my application read the buffer with XferData, it often returns 0. I put in code to do a second read in case the data I'm looking for is in the other buffer (I have it set up as a double buffer). I only get valid data about 25% of the time. I tried calling XferData right after the write that would trigger the read, and I tried it with a delay of 125us to 250us. It made no difference. I only got data about 25% of the time. The rest of the time the buffer was full of 0s and the length returned was 0.
I know ISO is not guaranteed data delivery, but a 75% data loss rate is pretty bad.
Anybody have any suggestions? I can post code snippets if that will help.
Bill
