STM32F407VG-Discovery USB Limits

communicationdataloggerstm32f4usb-host

I'm currently in the middle of my 3rd year university project and am trying to convert the STM Discovery board into a data-logger.
I've already found this site, which demo's how to make a GPS data-logger and should be a good springboard for me.

My question is twofold:

1) Is the STM's USB port capable of 15Megabits per second (15Mbps) data transfer?

2) I've read that there is a physical limit to the size of the USB stick that the STM can read, but have not found any reliable source for this. Does this limit exist, and if so, what is it?

To clarify, the data being transferred are raw AC voltages from numerous sensors, along with the type of sensor, time of reading, and a counter value. 7 sensors are audio and sampled at 100kHz (max frequency of interest is 40kHz), 144 sensors are sampled at 3125Hz, and a further 100 sensors are sampled at 391Hz. All 16 ADC pins are in use, along with SPI2.

Thanks in advance.

Edit: Here is the full calculated aggregate of the data being transferred:

(12bits * 100kHz * 7sensors) + (12bits * 3125Hz * 144sensors) + (12bits * 390.625Hz * 32sensors) + (16bits * 390.625Hz * 63sensors) = 14343750bits per second ~= 15Mbps

Best Answer

1) Is the STM's USB port capable of 15Megabits per second (15Mbps) data transfer?

No. The USB OTG socket is USB Full Speed, which means a maximum of 12Megabits/second. The other USB socket is connected to the hardware debugger, which is an STM32F103, which is only capable of USB Full Speed, 12Megabits/second, and goes via a much slower SWD interface.

EDIT:
Just to clarify how I concluded that DISCOVERY board only has USB Full-Speed on the socket:

The High-Speed-capable USB OTG port only has on-chip USB Full-Speed transcievers. To operate at High-Speed, it needs an external High-Speed PHY.

The STM32F407 datasheet says:

2.2.31 Universal serial bus on-the-go high-speed (OTG_HS)
The STM32F405xx and STM32F407xx devices embed a USB OTG high-speed (up to 480 Mb/s) device/host/OTG peripheral. The USB OTG HS supports both full-speed and high-speed operations. It integrates the transceivers for full-speed operation (12 MB/s) and features a UTMI low-pin interface (ULPI) for high-speed operation (480 MB/s). When using the USB OTG HS in HS mode, an external PHY device connected to the ULPI is required.

I looked at the STM32F4DISCOVERY datasheet for that discovery board. It has schematics for the board (section 6). Only the USB Full-Speed pins are connected to a USB socket, and there is no external High-Speed PHY. Hence it must be Full-Speed only.

However, it appears the High-Speed ULPI pins are available, so it is possible that you might be able to connect an external PHY etc. and get that to work. It might be worth digging around the st.com web site to see if they have an application note for that. However, I wouldn't automatically expect it to be easy. I don't know if the driver software is available, so unless you are very experienced and some test equipment to debug it, I'd recommend you check for driver software first.

END EDIT.

Further, USB FUll Speed's 12Mbps is a theoretical maximum which aggregates both data and control bandwidth. AFAIK, I'd be happy with 50% of that. IIRC, the software in the development kit wouldn't give 50% for 'normal' (non-lossy) transfers.

2) I've read that there is a physical limit to the size of the USB stick that the STM can read, but have not found any reliable source for this. Does this limit exist, and if so, what is it?

I am assuming you are using the USB OTG socket. I haven't experimented with this.

EDIT 2:
I don't know of any actual physical limit, but I find it easy to believe there are practical limits imposed by the USB Host 'Mass Storage class' software in the STM32 Discovery board libraries (or 3rd party libraries). They may be the limits that you have read about.

For example, if the USB stick is formatted with FAT32, then the maximum file size for one file on a FAT32 file system was 4 GiB minus 1 byte, (\$2^{32} − 1\$), or 4,294,967,295 bytes. That might be a limit you've read about, and might be a problem for your logger as your data rate is almost 2MB/second. So it could log for less than 40 minutes into one file.

(That could be fixed by using a sequence of files to log the data stream, eg write the first, say, \$2^{30}\$ bytes to eg. file 'log00001.dat', then close it and write the next \$2^{30}\$ bytes to file 'log00002.dat', etc)

Related Topic