STM32F103CBT6 usb interrupt end point transactions

[Vladimir Mitrofanov]

Hello, I can't cope with interrupt transactions. (I need it later for composite device).
For tests I generated HID device example. When device is connected to host it appears correctly in the system.
For interrupt endpoint configured 0x81.
I need to answer for interrupt transactions, but which callback is responsible for this?
I start debugging from very deep. Breakpoints were set in HAL_PCD_IRQHandler(). As I understand in this functions all usb transactions starts, but I see only interrupts from ZERO endpoint. Dumping by WireShark I see host sends requests to my device x.xx.1 and responses.
Why I don't see interrupts for 0x81 (also I check 0x01) in HAL_PCD_IRQHandler()?
What I do wrong?

[gbm]

It is IN endpoint, so normally an interrupt is generated after the data sent by your device is successfully received by host. You need to perform IN transfer.

[Vladimir Mitrofanov]

Thank you for your reply.
Can you a little bit clarify for me?
As I got all usb transactions it is about HOST.

IN - host receives
OUT - host sends
As I use IN (0x81) interrupt endpoint, host sends requests to device with configured period and device should reply for this requests.
I thought that after each host request interrupt will be generated and at this time I should send reply?

Where I am wrong?

[gbm]

The interrupt is generated when the host accepts data sent by you. You must send the data. After the data is sent, the interrupt means you may send the next packet.

[FBL]

Hi @Vladimir Mitrofanov 

Just few clarifications : The term interrupt endpoint describes the USB endpoint type, not a CPU interrupt source.

For an IN interrupt endpoint (0x81), the host periodically polls the endpoint, and your device must have IN data queued by calling USBD_HID_SendReport().

A CPU interrupt is generated only when that IN transfer completes, when the host has successfully received the data. 

You can set a breakpoint in USBD_LL_OpenEP() in usbd_conf.c to verify that your IN endpoint is properly opened, and then in USBD_LL_Transmit() to confirm that you actually start an IN transfer on that endpoint.

[Vladimir Mitrofanov]

Many  thanks. I have tested project and got interrupt as it was described earlier.
As a result data should be prepared before URB comes from host.
I thought the other way.
1. URB comes from host
2. Interrupt happed
3. Device reply.
As I see I was wrong.
Did I correctly understand that I should keep states for device when I send response during detection NCM device (CONNECTION_SPEED_CHANGE, NETWORK_CONNECTION).

[Vladimir Mitrofanov]

Can you explain me about buffer descriptor table (BDT)?
Is it fixed?
I have got behavior that I can't explain.
Dumping packets on host I got wrong data. Length is ok, but data is wrong.
In BDT I wrote correct address and length. Data wrote in pma (adress that is in BDT) is correct.
But when I stop in debugging address in BDT is changed. As I think in BDT there is a place for each endpoint (or it is like cyclic buffer?)
What I found if I set break point with "if" condition, just before sending address in BDT is OK, and data on host is OK.

It seems to me that I am working incorrectly with BDT.

 

[FBL]

Hi @Vladimir Mitrofanov 

This is a separate question from the original issue, so I kindly ask you to open a new thread for it. Feel free to tag me there, and I’ll be glad to help.

To keep this thread focused and efficient, let’s stay on the initial topic.

The device must prepare the data before the host polls the endpoint. The interrupt on the STM32 side occurs only when the IN transfer completes, after the host accepts the data.

If the original questions are now answered, consider accept the answer for this ticket and start new one for the BDT.

[Alexandercharli]

The STM32F103CBT6 USB interrupt endpoint is used for transferring small amounts of data at fixed time intervals. It is mainly used in devices like keyboards and mice where fast response is important. In this type of communication, the host computer regularly checks the device to see if any data is available. The data size is usually small and the transfer is time-sensitive, which means it focuses on quick delivery rather than large data transmission.