Hi all,
I'm writing a USB composite device support (baremetal) for MP135: it must support a custom interface and a CDC profile. Now I'm testing the CDC side connecting the USB cable with a PC: Windows mounts correctly a virtual serial port and I open a Putty serial session.
The board handles the USB data as input for a simple terminal.
This is what happen inserting a breakpoint on HAL_PCD_IRQHandler function (Drivers/STM32MP13xx_HAL_Driver/src/stm32mp13xx_hal_pcd.c):
- initially (after the port setup) nothing breaks
- on the first keypress on the Putty terminal the breakpoint breaks twice: the first with USB_OTG_GRXSTSP_PKTSTS = 2 (packet received) so read by USB_ReadPacket() - the second one with PKTSTS = 3 (transfer complete) so do nothing.
- the data read fires my callback that handles the received key generating an echo back to the terminal
- the interrupt is no more fired
- on the second key press the interrupt is fired but it does not contain the RXFLVL bit (USB_OTG_GINTSTS = 0x44888428)
- after a couple of breakpoint resumes the USB_OTG_GINTSTS turn to 0x4488843A and stay here forever, hanging the board in infinite loop of equal interrupts.
What happen? Now the GINTSTS contains RXFLVL but also contains MMIS (?).
The interrupt code contains the code:
if (__HAL_PCD_GET_FLAG(hpcd, USB_OTG_GINTSTS_MMIS))
{
/* incorrect mode, acknowledge the interrupt */
__HAL_PCD_CLEAR_FLAG(hpcd, USB_OTG_GINTSTS_MMIS);
}
but incredibly the if statement is not true (???).
Any help please!!
Regards
----- ADDED -----
Today (10/24/2024) additional tests. Now the (second press) behaviour is:
- in the endless recalls of the IRQ handler interrupt read always reports USB_OTG_GINTSTS = 0x44888428
- the board is alive (blinking red led) in a separate thread
- Wireshark only shows a URB_bulk out from host to destination: no reply from board (no data into the fifo...)
In this moment the DOEPINT1 reports vlue 0x2000 --> so NAK (?)
