USB Host stack and driver for STM32

[chibby]

Thanks for the reply moby,

So the talk of FTDI driver was a ( presumably windows ) host driver and nothing to do with STM32 ?

The STM32 target runs a simple command interface like the MEMS demo , is that the idea? This runs via the RS232 and can be linked to a true COM port on the host or via a USB-FTSI cable if the host can recognise FTDI .

I'm having some trouble with the OTG port under ChibiOS but I may be able to test this soon. The possibility of a properly working USB stack is enticing


I can get the MEMS demo working in the debugger but not standalone. The CDC device fails to work correctly with a Linux host. If I start it in the debugger and then continue , it recreates the device and then works fine. So it seems it can't be a big issue.

[dismirlian]

Hi Chibby and Mobyfab,

I'm sorry for the lack of updates... I've been very busy with work, so I couldn't even finish trying Moby's modifications.

Chibby:

What is this driver for? Is it intended to connect the USART via RS232 level converter into a DB9 to USB-A cable with built-in FDTI chip, then test the OTG port on the board, while keeping the STLINK dedicated to flashing and hardware debugging?

As Moby explained, this driver is to connect a FTDI USB-Serial to the STM32, NOT to the PC. The included drivers (MSD, FTDI, HUB) belong to the HOST side of the USB stack, so the STM32 acts as the host. To run the sample code for this driver, you should capture the output of the FTDI-based USB-serial converter connected to the STM32. To do that, you could use a PC's serial port (or another USB-serial converter).


Moby:

Sorry I haven't tested your code with my PCBs... I haven't found the time yet; I'll try to do it soon.


Happy new year to everyone!

Diego.

[chibby]

Thanks for the clarification. I was thinking of host/target in the debugging context, not as USB host, my bad.

So USB "host" is the one that gets the A-type connector, or OTG playing the transgender A-type role.

You're using true serial USART for debugging output. I now have that wired up via a max3232.

I don't have a lead with a micro A plug, not that common it seems. I wanted to wire up a standard type A socket next to the 3232 but it seems that not all the pins for that PHY are available on the edge connectors on the 407 discovery board.

[king2]

dismirlian, thank you for bringing hope to all of us dreamed of USB host in ChibiOS
Now I'm writing project where I should use USB flashdrive as storage and I was switched to CubeMX software just because ChibiOS had no USB host support.

Which status of your code now?
Is it included into official ChibiOS package?
Can I use it or it is still buggy and not recommended for production use?

Thanks!

[dismirlian]

Hi King2, it's just a minute contribution to a great project!

Regarding the status:

- only the STM32 is supported
- only full speed is supported
- the low level driver has a known bug when using accessing multiple peripherals at the same time through a hub. The bug manifests itself only when there is activity in both the devices saturating the USB bus.
- the MSD driver is functional, BUT error recovery is missing. I think it should be added for robustness of production code. I don't know if CubeMX's driver has implemented error recovery.
- you can use Chibios with CubeMX, it's been done before! It's not as beautiful as this code though .
- the code you should be using is mobyfab's ChibiosContrib repository, in case you agree to be a beta tester .

Thanks!
Diego.

[Giovanni]

Give it time to mature

Giovanni

[king2]

I cannot compile it with IAR
USB stack was written for GCC, as I see, so several places with ((packed)) I just changed to __packed before struct definition, same with alignment (was changed to #pragma).

But almost all macros from list.h cannot be compiled
For example, one of functions after preprocessor looks like this:

Code: Select all

    static inline usbh_port_t *usbhDeviceGetPort(usbh_device_t *dev) {
        return ({ 
            const typeof(((usbh_port_t *)0)->device) * __mptr = (dev); 
            (usbh_port_t *)((char *)__mptr - (__INTADDR__((&((usbh_port_t *)0)->device))));
        });
    }

It is used later as:

Code: Select all

   if (!(usbhDeviceGetPort(ep->device)->status & USBH_PORTSTATUS_ENABLE)) {
      _usbh_urb_completeI(urb, USBH_URBSTATUS_DISCONNECTED);
      return;
   }

This raises Error[Pe029]: expected an expression compiler error in usbh.h.
My C knowledge not so good to understand what this function should do - it returns code?
I cannot switch to other compiler now

How to make it compatible with IAR?

Thanks in advance!

[king2]

There is a problem with list.h, doubly linked list.
It uses typeof(), compound statements, which is accessible in GCC only

Is there any chance to use more compatible code that will compile in other compilers as well?

[king2]

Finally, I got it compiled with IAR.

I changed list.h and some sources due to absence of typeof in IAR, and changed format of packed and align.

With 512 byte block it gives me ~500Kb/s read speed and 230Kb/s write speed, but with blocks of 4096 bytes I got:

Code: Select all

BLK: Raw read test (1MB, 10240B blocks)
BLK: Raw read in 961 ms, 1065kB/s
FS: Block driver ready, try mount...
FS: Mounted.
FS: 487320 free clusters, 32 sectors per cluster, 3689283584 bytes free
FS: Write test (create file /test.dat, 1MB)
FS: Written 1MB in 1185 ms, 864kB/s
FS: Read test (read file /test.dat, 1MB, compare)
FS: Read 1MB in 1057 ms, 968kB/s
FS: Scan files test
FS: /SANDIS~1.0/DOWNLO~1.PDF
FS: /SANDIS~1.0/QUICKS~1.PDF
FS: /SANDIS~1.EXE
FS: /SYSTEM~1/INDEXE~1
FS: /TEST.DAT
FS: Tests done, restarting in 3s

I got this results using SanDisk 8G USB stick.

Some problems still exists.
2GB MyFlash (oldest USB stick I found) - 155Kb/s write speed (much more on PC).
8Gb Smartbuy - not works at all, gives:

Code: Select all

16383.000       HPRT: Port connection detected
16383.000  Port 1 connected, wait debounce...
16383.000  Try reset...
16383.004       HPRT: Port enabled
00018.760  Reset OK, recovery...
00118.754       DEV[CTRL]: Open EP
00118.778  Enumerate.
00118.785  Get first 8 bytes of device descriptor
00119.817  Configure bMaxPacketSize0 = 64
00119.859       DEV[CTRL]: Closing EP...
00119.883       DEV[CTRL]: Closed
00119.909       DEV[CTRL]: Open EP
00119.942  Set device address: 1
00120.087       DEV[CTRL]: Closing EP...
00120.112       DEV[CTRL]: Closed
00120.147       DEV[CTRL]: Open EP
00120.172  Wait stabilization...
00139.753  Get full device desc
00140.687  Enumeration finished.
00140.709  Loading langID0...
00143.638  langID0=0409
00143.657  Device has only one configuration
00143.668  Reading basic configuration descriptor 0
00145.168  Selecting configuration 0
00145.308  Device configured.
00145.316  New device found.
00145.324  ----- Device info -----
00145.332  Device descriptor:
00145.341       USBSpec=0200, #configurations=1, langID0=0409
00145.396       Class=00, Subclass=00, Protocol=00
00145.433       VID=13FE, PID=4200, Release=0100
00148.468       Manufacturer:         
00151.773       Product: USB DISK 2.0
00155.164       Serial Number: 90005B3479AF3542
00155.206  Configuration descriptor (partial):
00155.217       bConfigurationValue=1, Length=32, #interfaces=1
00155.271       Current=100mA
00155.293       SelfPowered=0, RemoteWakeup=0
00155.325       Name: 
00155.348  ----- End Device info -----
00156.714  ----- Configuration info -----
00156.725  Configuration descriptor:
00156.749  Configuration 1, #IFs=1
00156.778    Interface 0, alt=0, #EPs=2, Class=08, Subclass=06, Protocol=50
00156.848      Endpoint descriptor, Address=81, Type=2, MaxPacket=64, Interval=0
00156.919      Endpoint descriptor, Address=02, Type=2, MaxPacket=64, Interval=0
00156.981  ----- End Configuration info -----
00156.1000  Load a driver for each IF.
00157.012  Try load driver MSD
00157.038  BULK IN endpoint found: bEndpointAddress=81
00157.089  BULK OUT endpoint found: bEndpointAddress=02
00157.131  Reading Max LUN:
00158.180       max_lun = 1
00158.200       MSD[BIN ]: Open EP
00158.234       MSD[BOUT]: Open EP
00158.264  INQUIRY...
00159.402       PDT=00
00159.427  READ CAPACITY(10)...
00161.722       MSD[BIN ]: STALL
00161.780       MSD: Data phase: USBH_URBSTATUS_STALL
00161.792       READ CAPACITY(10): Transaction error

It sounds strange, but it worked and finished to work properly in endless tests and restarts of firmware. PC can read and write it.

What should I do with this USB stick? How to make it working? I think solving this problem will be useful to all of us.

I have attache my modified sources to this message.
If someone will make source files compatible to both compilers and will merge all this to ChibiOS-Contrib repo, it will be nice (I have no knowledge to do it by myself).

[dismirlian]

Hi King2, good job!

The solution for the pendrive that doesn't work:

The problem is the order of the operations TEST UNIT READY and READ CAPACITY. The order of these operations has to be inverted: in the file usbh_msd.c, in the function usbhmsdLUNConnect, invert the order of the blocks that send these commands. In this way, READ CAPACITY is executed only when the unit is ready, which is the logical sequence.

Sorry for the inconveniences....

Diego.