USB CDC on STM32F746 with ChibiOS 16.1

[Korken]

Hmm, it does not seem to get to the requests, only the line:

Code: Select all

if ((usbp->setup[0] & USB_RTYPE_TYPE_MASK) == USB_RTYPE_TYPE_CLASS) {

Is not true and it goes to false, but this happens all the time.
The default of the switch statement is never reached. Do you know what error this would indicate?

[Korken]

Just a thing I found through testing:
If I disable that check, everything works as it should. Is it possible that I have found some corner-case bug?

Code: Select all

void obqReleaseEmptyBufferI(output_buffers_queue_t *obqp) {

  osalDbgCheckClassI();
  //osalDbgAssert(!obqIsEmptyI(obqp), "buffers queue empty");

  /* Freeing a buffer slot in the queue.*/
  obqp->bcounter++;
  obqp->brdptr += obqp->bsize;
  if (obqp->brdptr >= obqp->btop) {
    obqp->brdptr = obqp->buffers;
  }

  /* Waking up one waiting thread, if any.*/
  osalThreadDequeueNextI(&obqp->waiting, MSG_OK);
}

[Giovanni]

The USB specification is thousands of pages, you can't expect me to remember all of it on demand. That if controls that the message is of the right type ("class").

I recommend you to read this: https://www.google.com/#q=usb%20in%20a% ... 20download

What you need it the format of the setup packets, it is a small free booklet and a good start.

Giovanni

[Giovanni]

Just a thing I found through testing:
If I disable that check, everything works as it should. Is it possible that I have found some corner-case bug?

Code: Select all

void obqReleaseEmptyBufferI(output_buffers_queue_t *obqp) {

  osalDbgCheckClassI();
  //osalDbgAssert(!obqIsEmptyI(obqp), "buffers queue empty");

  /* Freeing a buffer slot in the queue.*/
  obqp->bcounter++;
  obqp->brdptr += obqp->bsize;
  if (obqp->brdptr >= obqp->btop) {
    obqp->brdptr = obqp->buffers;
  }

  /* Waking up one waiting thread, if any.*/
  osalThreadDequeueNextI(&obqp->waiting, MSG_OK);
}

It is the same as sweeping the dust under the carpet and pretend that the room is clean. There could be a bug but that is not the solution.

What I need is a way to replicate the problem.

Giovanni

[Korken]

The USB specification is thousands of pages, you can't expect me to remember all of it on demand. That if controls that the message is of the right type ("class").

I recommend you to read this: https://www.google.com/#q=usb%20in%20a% ... 20download

What you need it the format of the setup packets, it is a small free booklet and a good start.

Giovanni

Indeed not, but since you wrote the driver you know a lot more than me
On the "USB in a nutshell", I have read it many times. A good primer to USB without to much detail.
I will have a look at it again, see if I have missed something about class.

It is the same as sweeping the dust under the carpet and pretend that the room is clean. There could be a bug but that is not the solution.

What I need is a way to replicate the problem.

Giovanni

I can replicate the effect:
When using a Linux computer (tested on 2 Arch based ones so far), run the a serial monitor "mincom -D /dev/ttyACMx" (or any other) where x is the number the board got.
Every time it opens and tries to open the port the board hangs with the described problem.

If you need more info I can give whatever you request.

[Korken]

I have now confirmed the same error happening on a STM32F4 board as well.

[Korken]

The problems seems to be that a transfer has finished that has a length > 0 (it is always 6 when the error occurs), but the read and write pointer for the queue are equal.
This causes the asset to fire:

Code: Select all

USBD1.epc[1].in_state->txsize = 6

Code: Select all

SDU1.obqueue = {
  waiting = {
    p_next = 0x20001414 <SDU1+64>,
    p_prev = 0x20001414 <SDU1+64> 
  },
  bcounter = 2,
  bwrptr = 0x20001650 <SDU1+636> "\006",
  brdptr = 0x20001650 <SDU1+636> "\006",
  btop = 0x20001858 <SDU1+1156> "XY",
  bsize = 260,
  bn = 2,
  buffers = 0x20001650 <SDU1+636> "\006",
  ptr = 0x0,
  top = 0x0,
  notify = 0x202441 <obnotify>,
  link = 0x200013d4 <SDU1>
}

I have also tested on Windows 10, then this error does not occur.
Not sure if this helps, but maybe.

[Giovanni]

I need to think a bit about that condition, it is strange it is not triggered under windows.

Giovanni

[Korken]

Please do
It's about now I wish I knew USB drivers better so I could be of more help.

I have now also tested with trunk instead of 16.1.x, just to check but the error is there as well.
(But still working on Win 10 with trunk as well).

[seawalker]

Hi,

my first post here ! Thanks Giovanni to share and support us.

I confirm USB CDC on STM32F405( Olimex P405) on Linux (FC23) => no ttyACMx...?

As I just read the topic, I will do the checks as mentionned by Korken and Giovanni and turn back soon.

Saluti da Ragusa al sole !...

Gilles