Extra USBD characters in hpcd->OUT_ep->xfer_buff

[ZThat]

Disclaimer: I am using V1.14.0 and have not edited the HAL or LL divers. I am running the chip at the USBD CDC example project settings. I am communicating at FS.

I am seeing this(hpcd->OUT_ep->xfer_buff) buffer populate with additional/non-existent characters when sending messages to the board. As soon as I send a message to the board, this buffer populates with the additional characters (not the sent character), then I allow the HAL_PCD_DataOutStageCallback function to call and this buffer fills with the message that I sent and keeps the additional/non-existent characters at the end. I have checked and seen that the actual memory register space (USBx_DFIFO(0)) that receives these messages filled with the actual sent character and non-existent characters (it does not "fill" this 1000 byte space. It fills the first few bytes that contain my sent message and the additional characters). This space being 0x50001000 on my stm32f7xx chip. This space is set to zero before enumeration, then after enumeration this memory space fills in an interesting way, that changes each time a message is sent. I will attach an image. The 00 and 01 remain consistent, however, the 67 that you see changes after each message to a new random character.

Upon further inspection, this buffer that fills with additional characters (xfer_buff) and then fills with the whole message goes through an interesting lifecycle. It first fills with the sent character and the additional characters (this period of its life coming before my previous story), with the USB_ReadPacket function. Then it gets rid of the first character (the character that I actually sent) in the following line of code. Both lines of code shown below.

     (void)USB_ReadPacket(USBx, ep->xfer_buff, (uint16_t)((temp & USB_OTG_GRXSTSP_BCNT) >> 4));

     ep->xfer_buff += (temp & USB_OTG_GRXSTSP_BCNT) >> 4;

This leaves it with only the additional/non-existent characters until the callback function discussed previously.

I have seen this lead to all kind of issues. These buffers and memory space seem to fill with the messages that I transfer from the board to the PC if I use a certain terminal program. That is to say, the issue vary depending on the type of terminal program that I use to communicate. I have sniffed the com port and seen that these additional characters are not actually travelling back and forth. This is a driver issue. The memory space seems to be filling with nonsense and that nonsense ends up inside of my messages.

Has anyone else seen this issue? I have seen it on two different chipsets at this point (aka. my eval configuration and prototype configuration).

I might be able to use some fancy code that knows what nonsense to expect and gets rid of the nonsense, but this seems like something that STM should be interested in and aware of.

[waclawek.jan]

> (USBx_DFIFO(0))

>0x50001000

You are not supposed to read that area through the debugger, doing so messes up the internal registers of the OTG module.

If you don't observe the FIFO in debugger and still have surprising characters incoming, that might be the terminal program trying to transmit some sort of framing, XON/XOFF, UNICODE characters, etc.

JW

[ZThat]

​This issue happens in and out of debug mode. The extra characters do not appear in when sniffing the com port communication.

[waclawek.jan]

What I tried to say above is, that using the debugger to look at FIFO you are unlikely to reveal the source of problem, but almost certainly make things worse.

You said above that

> the issue vary depending on the type of terminal program that I use to communicate

so the source of the problem appears to be on the PC side, isn't it?

I don't know what exactly do you mean by "sniffing the com port communication".

JW

[ZThat · Accepted solution]

​I use a serial port monitor provided by Eltima. I will attach a screenshot showing that only an "i" was sent. However, my hpcd->OUT_ep->xfer_buff and eventually my UserRxBuffer fills with "i€‘" also known as 0x69 0x80 0x91. This is when using terraterm. But if I were to use a different terminal program, I would see a different message.

I have actually solved this issue by saving the length of the message received in a static variable to access later. This length gets passed through the callback structures of the interrupt. Previously I had been calculating the length of the message buffer with a strlen command. The moral of the story being, don't ever calculate the length of the received buffer on your own when using STM32F7 USB device drivers. Use the length that they give you in the callback. The read buffer gets filled with all kinds of nonsense that varies depending on all kinds of factors, but the beginning of it will be the correct message.

[waclawek.jan]

Thanks for coming back with the solution. Please mark your post as "best" so that the thread is tagged as solved.

JW