Thank you very much dsigma for your answer
dsigma wrote: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)
dsigma wrote: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
dsigma wrote: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.
dsigma wrote: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.
