Extra USBD characters in hpcd->OUT_ep->xfer_buff
- January 21, 2019
- 5 replies
- 1583 views
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.
