Getting a USB stack to work on STM32

[petex]

hello,
I have got the USB stack by Laksen (mentioned in a previous post on USB) compiled and running on the STM32 Bluepill.
From what I can see and trace, the code is working as intended and valid config packets are sent back to the host.

It is configured for a CDC USB class which is supposed to be supported by Windows 10 with a generic driver.

When I plug in, the device is recognised and added to the devices page. It defines a virtual com port, but there is an error 10. (device not started) which is pretty unhelpful. The port cannot be opened.

I have attached the relevant properties pages :-

[petex]

Made some progress with this stack ....
I installed a virtual com driver from the ST microelectronics site. I also changed the VENDOR and PRODUCT codes in the device descriptor to match this driver. It has installed a virtual com port in Windows 10 with no errors this time. When i type stuff in the terminal to this com port I can see the data transfer using a USB monitor tool, but not got the data out at the STM32 end yet.

Code: Pascal  [Select][+][-]

1.  devDesc: TUsbDeviceDescriptor = (
2.    bLength: sizeof(TUsbDeviceDescriptor);
3.    bDescriptorType: USB_DESC_TYPE_Device;
4.    bcdUsb: $0200;
5.    bDeviceClass: 0;
6.    bDeviceSubClass: 0;
7.    bDeviceProtocol: 0;
8.    bMaxPacketSize: CDC_EP0_SIZE;
9.    idVendor: $0483;
10.    idProduct: $5740;
11.    bcdDevice: $100;
12.    iManufacturer: 1;
13.    iProduct: 2;
14.    iSerialNumber: 3;
15.    bNumConfigurations: 1
16.  

[Laksen]

Try to check that it's not stuck in the UsbSend function

Can you show what transfers it's transmitting?

[petex]

success, I have program looping back received data. Characters typed on terminal on windows are looped back ok.

The code is compiled with the MBR compiler toolset and incorporates the MBR framework for the setup and timer. The Laksen units are unchanged. The unit "stm32f103fw" has been altered to fit with the MBR framework. I have also altered the main program to change the configuration packets and to simplify somewhat.

[Laksen]

Good to hear, what did you change to fix it?

[petex]

I was getting RX to work but not TX.
I had different endpoint addresses for the RX and TX endpoints. I set them to $01 and $81 i,e, address 1 and i started to get TX request events and transmission of data started.

[MiR]

Like it!

I am a USB-noob myself, would you mind sharing your code? I'd love to put an example in MBF.

Modern USB Stacks (tinyusb) do not need a vendor specific driver for windows, any idea what they do different?

Michael

[PascalDragon]

I am a USB-noob myself, would you mind sharing your code? I'd love to put an example in MBF.

Laksen's USB stack is available here.

Modern USB Stacks (tinyusb) do not need a vendor specific driver for windows, any idea what they do different?

They probably report vendor/device IDs that Windows supports out of the box.

[Laksen]

I am a USB-noob myself, would you mind sharing your code? I'd love to put an example in MBF.

Laksen's USB stack is available here.

In case anyone's interested I have a big redesign on the feature_simpleusb branch that makes creating compound devices, and in general adding USB capability to a design a lot simpler:

https://github.com/Laksen/fp-usb/blob/feature_simpleusb/example_cdc/test.lpr#L205

[MiR]

Have you ever tried how portable your stack is between stm* devices?

Currently my thinking was that if I ever need usb it is way easier to integrate something like tinyusb which is available for all major stm32 chips (and also atmel d21/51 and esp32)
but your code looks pretty slim.....

Michael

[petex]

I am a USB-noob myself, would you mind sharing your code? I'd love to put an example in MBF.

I shall get a release together of what is currently working. I still have a problem with it hanging when I try to do some heavy lifting. i.e. I have a simple request/response protocol going between the STM32 and PC test application. It works OK for a while and then hangs waiting for a response back from the STM32. When I monitor the USB it looks active with tx requests so it looks like a tx back to pc has failed.

I shall try and base an example on some very recent changes to simpleUsb and see if that works any better.

[avra]

It works OK for a while and then hangs waiting for a response back from the STM32.

Do you have a watchdog and brown out protection? Or at least a flashing led as an indicator that STM32 is not hanged?

[petex]

Do you have a watchdog and brown out protection? Or at least a flashing led as an indicator that STM32 is not hanged?

Early stages my friend !!
The program should not hang as it is and there is some bug that I need to identify. I am starting at the start and getting bits to work stage by stage.

[Laksen]

The old code did have some bugs that are fixed in the simpleUSB code. Primarily that it could lose bulk tx transactions and write too much to the endpoint overflowing the host controller probably leading to a disconnect or bus reset

[petex]

hello,
I have discovered how to load the Windows generic serial driver. Microsoft  have a designated class and sub class codes to select the "usbser.sys" driver. So I don't need the STM micro one, i was using....

Code: Pascal  [Select][+][-]

1.   DataIntf: (
2.       bLength: sizeof(TUsbInterfaceDescriptor);
3.       bDescriptorType: USB_DESC_TYPE_Interface;
4.       bInterfaceNumber: 0;
5.       bAlternateSetting: 0;
6.       bNumEndpoints: 2;
7.       bInterfaceClass: 2; // WIN GENERIC codes
8.       bInterfaceSubClass: 2;
9.       bInterfaceProtocol: 255;
10.       iInterface: 2;
11.     );    
12.  

I merged in your changes to the UsbHal unit from the simple usb project.


I am still getting the hang problem. The request/response transactions stop after the 50 - 250 point. I don't think the bug is in my PC program as I have it working normally using the PC uart com port and using the FTDI usb card.

When it hangs, the PC is battering the STM32 with Tx requests and these trigger in the USbHal unit... The program on the STM32 is active and I can debug it ok,

Code: Pascal  [Select][+][-]

1.     reg := @USB.EPR[endpoint];
2.     if (reg^ and USB_EP_CTR_TX) <> 0 then
3.  

At this point no data  receive events are triggered on the STM32 although it is polling for it.

When I close and open the port, some setup packets are sent by the PC and these trigger the receive events ....

Code: Pascal  [Select][+][-]

1.       reg^ := reg^ and (USB_EP_MASK xor USB_EP_CTR_RX);
2.       if (reg^ and USB_EP_SETUP) <> 0 then
3.         event := TDriverEvent.deSetup   // <<<<<<<<<<<<<<<<< THIS ONE TRIGGERS
4.       else
5.         event := TDriverEvent.deRx;  
6.