STM32F107 OTG Mass Storage ultra slow

[Hrbrgr]

Hi,
I've been working with dsigmas code on a STM32F4 Discovery Board.
I got SDIO working and have access to my SD card over OTG1 FullSpeed but ran into some problems, I hope somebody is able to help me.

My problems:

I try to use VCOM and USB mass storage over one port. And both is kind of working.
After everything is initiated I chprintf() a test string in a while loop with a delay between turns of 1000ms.
I see the string in my terminal, but after about 1min it stops, and the led, which is toggled in the same loop freezes too (hung up in chprintf?).
First I thought some buffer runs over, but I tried the same with only 100ms delay and got of course a lot of more strings in my terminal, but it stops again after about 1min.

That's my first problem. Additionally I have to wait about 2min for the SD Card to pop up in windows. In the device manager USB Mass storage device is shown like virtual com port almost immediately after I plug in the usb cable, but then it takes it's time to be shown in the explorer.

I hope someone is able to help.
Many thanks in advance

-Hrbrgr

[Giovanni]

Hi,

Are you running with the debug options enabled? those could help understanding the problem.

Giovanni

[Noname]

Hello

I have some question about dsigmas code and its composite USB MSD+CDC driver.
Has anyone a working version of the dsigmas code for an STM32F4 Discovery board (->without ULPI chip, SPI SD instead of SDIO)???

Compared to the original code from DSigma, I have changed the following things:
- disabled all the STM32_USE_USB_OTG2 stuff (since there is no ULPI on the discovery board) and enabled OTG1 in the mcuconf header file.
- modified the ports of the LEDs to use those on the discovery board.
- modified the board file of the discovery and added/moddified those pins according those used on the board from dsigma, except those ons, I don't need:

• *_OTG_HS_ULPI_*
• GPIOA_WAKE_BUTTON
• GPIOD_SERIAL_2_*
• GPIOE_JOYSTICK_*

It compiles, but the code seems to freeze at the function msdInit().
(Well I have no SD card attached, but I should have had at least a VCOM port if connected to the PC)

Can someone help-me please?
I'm a beginner, my knowledge about microcontroller are limited, I have only played around with .NetMF, which is much more userfriendy but too limited.

Thank you

[Noname]

Hi

I got it to work with en SD card in SPI mode (If only I had known that pull-up restitors on the SPI lines were needed, I wouldn't have lost so much time... ).

But I have an issue, the STM32/SD doesn't appear as an USB Key (mass storage device) on Windows drives list :/
How is that possible? Isn't that possible with a composite device?
Do I need to write my own Driver for Windows? :/




EDIT:
Well, the MSD works actually, the drive appear on Windows explorer after 1-2 minutes. A little bit too long to wait, is there a way to correct that bug???
I have no Com port that appears on Windows :/

[dsigma]

Hi,

In regards to the MSD taking 1-2 minutes to show up in the host OS, I did experience this issue early on, and after some investigation I found that it was due to long command processing times (by long, it was like on the order of 10's of milliseconds), combined with the fact that windows needs to run many requests for what I believe is the FAT table. I ended up debugging this by twitching GPIO lines during command handling in the MSD driver and looking at it on an oscope (note: avoid chprintf from the MSD threads. chprintf to a serial port is really really slow compared to the expected speed of the MSD driver and will severely bog down the MSD driver and make it take forever to show up in the OS). Basicly, if you multiple a number like 20ms by 5000, you are already in the time range of minutes. In my test case, I never saw 2 minutes, but I did see 30s-45s. But this may be a function of the size of the FAT (or whatever windows is reading). I had a small SD card for my initial testing.

It sounds like your using SPI, so if for some reason the individual SPI transactions were taking a long time (like 10's of milliseconds), that multiplied by thousands of requests from the OS can quickly add up...




In regards to the VCOM issue, I have received one other report of windows not working cleanly with the USB composite device. More specifically, the VCOM driver needed to be manually unloaded and re-loaded to get the VCOM device to work. However, Linux and modern versions of MacOSX worked fine. Note: old versions of macOSX don't support composite devices at all. I'm not sure why windows has issues with composite VCOM devices, partially because I haven't had time to investigate, and partly because I'm not a windows person and I've always found it difficult to find low level technical information about the behavior of windows. Perhaps there's someone else out there who knows more then me?



In regards to the freezing behavior you observed with MSDInit(). I looked at the init code and it has this:

Code: Select all

while (TRUE) {
    blkstate_t state = blkGetDriverState(bbdp);
    if (state == BLK_READY)
      break;

    chThdSleepMilliseconds(50);
  }


My guess is that the SPI device driver is never getting into the "BLK_READY" state, and that it spinning forever.
I think that 2 things need to happen to this code:
1) it needs a timeout, waiting forever is not an appropriate behavior for a block device that can't become ready. The init function should return an error code. I'll make this change and get it committed to the repo.
2) You should investigate the SPI SD driver to figure out why it's not becoming ready. I've not used the MSD driver with a SPI based SD card, but so long as the abstract block device driver behaves with those semantics, it theoretically should work. However... believe it when you see it...





It sounds like your new to embedded systems programming, so I have a time saving tip for you. When your code freezes, you can manually halt the CPU with your jtag adapter and program (I use OpenOCD), and look at the CPU registers and instruction pointer. Then, you can take your output ELF file and do a full assembly dump of it, and go to the line of code that caused your problem, and see what respective C-code generated that line of assembly, and get a pretty good idea of where things are going wrong. If your using gcc, make sure to pass '-g' when compiling, that way your output list file will contain both assembly code and C-code with file names and file line numbers.

[dsigma]

Update: I've updated the MSD code, merged with the latest upstream/master Chibios code and pushed to my repo....

[Noname]

Thank you very much dsigma for your answer

Hi,

In regards to the MSD taking 1-2 minutes to show up in the host OS, I did experience this issue early on, and after some investigation I found that it was due to long command processing times (by long, it was like on the order of 10's of milliseconds), combined with the fact that windows needs to run many requests for what I believe is the FAT table. I ended up debugging this by twitching GPIO lines during command handling in the MSD driver and looking at it on an oscope (note: avoid chprintf from the MSD threads. chprintf to a serial port is really really slow compared to the expected speed of the MSD driver and will severely bog down the MSD driver and make it take forever to show up in the OS). Basicly, if you multiple a number like 20ms by 5000, you are already in the time range of minutes. In my test case, I never saw 2 minutes, but I did see 30s-45s. But this may be a function of the size of the FAT (or whatever windows is reading). I had a small SD card for my initial testing.

It sounds like your using SPI, so if for some reason the individual SPI transactions were taking a long time (like 10's of milliseconds), that multiplied by thousands of requests from the OS can quickly add up...

Actually, I already disabled the debug mode of the driver and removed all chprintf in main.c(I don't need them because the messages don't appear on the Eclipse Terminal, I don't know why . Instead I'm using an character LCD + uGFX). It didn't solve the problem :-/
I used a software USB analyser (USBlyzer) and I noticed those things:

Start @11:32:27.646

1. From the beginning @11:32:27.646 until 11:34:41.562 (-> 2min 14s) nothing happens except those repeated strange errors:

Code: Select all

Bulk or Interrupt Transfer   in   01:02:83   FFFFFA8006857440h   USBPDO-11   usbhub   FFFFFA800AE75BD0h   Unsuccessful (Stall PID)
Bulk or Interrupt Transfer   in   01:02:83   FFFFFA800B89FA00h   0000013b   usbccgp   FFFFFA800AE75BD0h   Unsuccessful (Stall PID)
...
Bulk or Interrupt Transfer   in   01:02:83   FFFFFA8006857440h   USBPDO-11   usbhub   FFFFFA800AE75BD0h   Cancelled (Canceled)
Bulk or Interrupt Transfer   in   01:02:83   FFFFFA800B89FA00h   0000013b   usbccgp   FFFFFA800AE75BD0h   Cancelled (Canceled)
...

2. @11:34:41.567 it sends several times 512 bytes 0s

3. @11:34:41.624 the MBR is sent to the PC for the first time, and the drive appears on Windows shortly after that.

May the Unsuccessful (Stall PID) and Cancelled (Canceled) errors be the reason for the delay???
It's strange, when I trace the commands of a standart USB Key, there is much less trafic.

Yet another thing, I'm using the USB OTG 1, I dont have an ULPI chip, so I'm limited to USB FS speed.
(The SD card is an empty Transcend 2GB)

In regards to the VCOM issue, I have received one other report of windows not working cleanly with the USB composite device. More specifically, the VCOM driver needed to be manually unloaded and re-loaded to get the VCOM device to work. However, Linux and modern versions of MacOSX worked fine. Note: old versions of macOSX don't support composite devices at all. I'm not sure why windows has issues with composite VCOM devices, partially because I haven't had time to investigate, and partly because I'm not a windows person and I've always found it difficult to find low level technical information about the behavior of windows. Perhaps there's someone else out there who knows more then me?

I will try it on a Linux VM

In regards to the freezing behavior you observed with MSDInit(). I looked at the init code and it has this:

Code: Select all

while (TRUE) {
    blkstate_t state = blkGetDriverState(bbdp);
    if (state == BLK_READY)
      break;

    chThdSleepMilliseconds(50);
  }


Yep exactly, I also had the same freezes, actualy, the SD card was effectivly detected, FatFS mounted, but connection were lost shortly after that.
I added the pull-up restistors on the SPI lines and the problem was solved, for me at least, maybe there was another problem with Hrbrgr's solution.

It sounds like your new to embedded systems programming, so I have a time saving tip for you. When your code freezes, you can manually halt the CPU with your jtag adapter and program (I use OpenOCD), and look at the CPU registers and instruction pointer. Then, you can take your output ELF file and do a full assembly dump of it, and go to the line of code that caused your problem, and see what respective C-code generated that line of assembly, and get a pretty good idea of where things are going wrong. If your using gcc, make sure to pass '-g' when compiling, that way your output list file will contain both assembly code and C-code with file names and file line numbers.

I'm using ChibiStudio, but I don't know exactly yet how to use OpenOCD. The connection seems ok because the LED1 of the programmer side of the Discovery turns green, but I don't know how to access the registers .
Also I can't read chprintf, nothing appear on the terminal in Eclipse.

I think I really need to read some documentation/tutorial first.

[Noname]

Ok, have tested on an Ubuntu VM and the volume is mounted within seconds as any other USB key. The Com port works also.

So I would say that it may be the error on de CDC Interface that generates that delay on Windows :-/.

Other infos.
I needed that the Chibi MSD to be mountable at PC bios boot. I have tested on 2 different motherboards, on the a Asus the Chibi MSD Key is recognized, on the Intel motherboard, the bios boot sequence freezes :-/, well not exactly, if I press the reset bouton of the STM32, the bios boot process continues, so I would say the motherboard bios is waiting for somethings from the Chibi MSD Key :/.

[Giovanni]

The CDC implementation does not handle ALL the possible CDC message, is it possible Windows tries to sent an unsupported message? that would cause a message rejection and possibly several retries of the host.

It is possible to put a breakpoint in the CDC messages code and verify this.

Giovanni

[Noname]

Well have juste tried another USB descriptor but without CDC, only MSD (present on this demo from dsigma ).

And there again, on Linux, the volume is mounted immediately. On Windows the volume/drive doesn't appear at all, even after 10 minutes.

Another strange thing with that version (MSD only). Why does the device appears as a "Composite device" and not as an "Storage Media" like any other USB key?? In the USB descriptor it is clearly mentionned that is a "Mass Storage, SCSI Transparent Command Set, Bulk-Only Transport" device, and nothing else, since there is no CDC interface declared.

Wierd