USBB Difficulty

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

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???

Regards

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

As follow up I added some code in the transmission routine that checks for non-zero BYCT value at the entry (it is always zero).

Then, copies the data and checks the byte count after each byte copy. If the byte count increments to a value greater than the number of bytes copied it stops copying and adds the byte count read:

        while (usLength--) {
            *ptrDPRAM++ = *ptrData++;
            usBytesWritten++;
            ulBufferContent = (unsigned short)((UESTA0 & BYCT_MASK) >> BYCT_SHIFT);
            if (ulBufferContent > usBytesWritten) {

                *ptrDPRAM = (unsigned char)ulBufferContent; // the bad value
                break; // something has gone wrong -. send what we have to see
            }
        }

The results are as identified with the debugger. It always happens when writing the first byte and the new byte count is always detected as being 4. Although the first byte written is always 0x00 I have found that the 4 bytes of data which get entered in to the DPRAM are not always 0x00 (when I start a terminal emulator on the virtual COM it requests 4x the same and I see it getting set with 0x00 the first 2 times, then with 0x80 and then with 0x90.

I tried to correct the data once it was detected as being corrupted but this doesn't seem possible. Once copied to the DPRAM the count value can't be decremented without sending it (possibly by resetting the endpoint but that would probably not be possible on endpoint 0?).

By sending short data in place of the corrupted data (0x00 0x00 0x00 0x00 0x04 is sent the first time) the USB host in acknowledging the frames (again), so this seems to be content dependent and probably not a further problem.

So the question remains - how can a single byte write be interpreted as 4 (with content change in some cases)???

Regards

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

Final piece of info before giving up for today:
- When the error is detected it is possible to disable and re-enable the control endpoint 0. Then the data can be repeated and it is correct (that is, 7 bytes long with the correct content).
- Unfortunately the data toggle is set to 0 after the re-enable, which means that a DATA0 frame is sent, rather than a DATA1 (which is rejected by the USB host since it is an error - although acked on the bus). It looks as though the only way to get a DATA1 sent is after receiving a SETUP. Therefore this is not a workaround but does illustate that the basic problem is reset after the endpoint is re-enabled.

Any ideas?

Regards

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure you're not viewing any status registers in the debugger. I know that can cause things to mess up on other peripherals like TWI and USART.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Yes, I have also had such effects (it is not advisable to watch the DPRAM when debugging, for example but the USBB registers themselves seemed harmlos since reads don't cause anything to be reset - there are CLEAR registers for must registers).

However the effect is the same when running release code and not just when debugging - that is also why it is sometimes a good idea to use some run-time debugging like I did to get the code to check for the effect that was seen with the debugger (which also verified it) and attempting to correct the situation as a workaround.

[i]I haven't done any more work just yet since I was exhausted after working through Saturday night believing that I must be able to solve it before getting to bed...[;-)/i]

Regards

Mark