I am working with UC3A and UC3B parts with USBB controller - [USB device mode].
The following effect is consistent (using a new driver and not from framework - the framework one hangs when there is a USB reset at an inappropriate time so a different solution is being attempted). The effect is consistent (every time the same - 100%):
1) During emumeration of a CDC class the enumeration sequence is normal. There are a few descriptor requests from the host and all are answered correctly. This involves (on 8 byte control endpoint 0) sending data responses of 18, 67, 34, 4, 16, 18 and 67 bytes length (these are of course multiple INs of 8 bytes and some shorter closing INs and sometimes zero data frames (3 in fact in total).
2) Then the host sends a class request 0x21 IN and this fails. Every following IN fails in exactly the same manner:
- the code clears the SETUP bit to free the control endpoint's dual-port RAM, the writes 7 bytes to the DPRAM (at 0xd000000..0xd0000006 on UC3B) and then clears the TXINI bit so that the content is sent.
- the problem is that '8' bytes get sent out (not 7) and the host doesn't acknowledge them (I don't see why there is no ack but the fact that 8 bytes are sent instead of 7 is already a problem.
- as noted before, this is every time and also on every following repeat of the class request 0x21 IN (request of serial port setting).
3) So I spent (a lot of) time debugging to see what could be happening and the following is consistent:
- when the 7 bytes are written to the DPRAM the byte counter gets incremented from 0 to 4 on the first byte write. On the second byte write from 4 to 5 and so on (maximum 8)
- the data written by the 7 byte writes are 0x00 0xc2 0x01 0x00 0x00 0x00 0x08
- the data sent out are 0x00 0x00 0x00 0x00 0xc2 0x01 0x00 0x00. What is seen is that the first 0x00 is sent out 4 times (consistent with the observation that the byte count jumps to 4 when the first byte is written).
Note that the data write routine used to send the control endpoint data is the same for all of the data in the sequence (the first approx. 200 bytes are fine and then it always does this). After a disconnect and reconnect the exact same sequence is repeated.
Note also that the write is being performed with global interrupts disabled so there is no chance of interrupts jumping in and doing strange things.
Further note that the exact same thing happens when the write is performed immediately on reception of the class request 0x21 or if it is delayed ( eg. by setting a break point with the debugger) by up to 20s (after about 20s the USB host repeats the SETUP token which then overwrites the DPRAM area again).
I ran CDC demo code from the framework on the boards and stepped through the code and didn't see any differences in any register settings or in the sequence used to respond to the data. This code didn't have the same effect (although it hangs when there is a USB reset while waiting for certain flags, which means it requires some modifications before it could be used productively).
I am wondering how a single byte write can be interpreted as 4 writes? Could it be a clocking issue somewhere - I am running the PLL and CPU at 48 MHz so that the USB can directly use it.
Anyone experienced this or has any ideas???