Recommended USB device schematic? STM32F1 - Page 1
Forum section: electronics / general

author: jnz
author_rank: Frequent Contributor
timestamp: June 15, 2015, 02:26:13 am
content: I have a full-speed device that will self-power from 12V when it's installed/in place. When pulled out and hooked to a PC where it'll appear as a mass storage device, in order to quickly update settings via a text/xml/ini file.I've never made a USB circuit before so I'm wondering about certain aspects...1. The STM32F1 chip I'm using has internal pull-ups. Is there any reason I would use external for the data lines? I have schematic examples on dev boards that show both. In high speed I see the need to switch so some designs use a bjt. Not for me I'm pretty sure.2. There is an EMI/ESD chip I like for the D+/D- lines. And 22ohm resistors in series for each of those. Are there any other protections I might want to consider?3. When plugged into a PC, everything in my circuit should be off except for the micro to transfer the file. But I don't want disconnect or sporadic errors that might come with being a hub powered device. Anything I might want to consider for the power supply? My 12V source hooks to a special 3.3V supply for the chip now, but I can't drive that with 5V from USB so I'll need an additional LDO to power the micro in the limited mode. Any issues with tying this 3.3V into my other 3.3V source? I've never had dual regulators before and didn't know if there were diode/back feeding or runaway concerns if both happen to be running.Anything else I should concern myself with? When I get into USB OTG it'll get more complicated I'm sure but for now it seems fairly easy to use the PHY inside of the STM32F1 make a full speed msc device. I'd welcome any input,

author: BennVenn
author_rank: Regular Contributor
timestamp: June 15, 2015, 02:52:15 am
content: Hi,The pull up on the data lines - The resistor value tells the host a few things about the device. I believe it is a 1.5k pull up that initiates handshaking with the host. The internal pull up is around 10K? It's always been done with an external pull up resistor but that is not to say it must be. To conform to the USB spec I'd stick with the 1.5k. I connect this to another GPIO and kick off the interface when I'm ready rather than have it hard wired.ESD can be as complex or as simple as you feel comfortable with. What kind of environment will it end up in?What is the mass storage you intend to use? Flash? SD? EEPROM? In most cases you can disable the device so current draw shouldn't be at such a level to trigger brown outs or connection errors. In which case, you may be able to use the existing 5v-3.3v LDO reg. You'll have a lot of ROM spare in the STM32 to store settings etc...I've finshed coding a USB MSC driver in pure assembly on the STM32F103. There are quite a few layers of protocol you need to deal with and you need to think about your file system too. Plus the block size the MSC driver operates at is typically 512 bytes which is almost certainly smaller than the block size of the storage you'll be using. This means Read-Modify-Erase-Write for generic file system access unless you emulate the FAT and manage file handling internally.Is this your first attempt as USB interfacing?

author: jnz
author_rank: Frequent Contributor
timestamp: June 15, 2015, 04:39:44 am
content: Yes. First attempt at USB. However, I'm using the Keil Pro middleware for RTOS, USB device, MSC, and file system. So the software effort on my part SHOULD be very low. Yes, mass storage class to internal Flash. It's not even 100% vital to this project but I'd like to implement for quick settings changes via USB without full reprogramming.Haven't looked at elec specs on the pull-ups. But why would they be 10k if the spec is 1.5k. And yea, you're right it's 1.5 up and 10.5k down iirc.Gpio 3.3v vs transistor 3.3v... I've seen some schematics that use a transistor to drive the pull-up others that use a gpio and others that were hard wired. Why the transistor? Vs a gpio I suppose someone must feel that using a transistor further protects the line going back to the micro?

author: BennVenn
author_rank: Regular Contributor
timestamp: June 15, 2015, 04:51:45 am
content: Sounds much easier taking the Keil library approach.10k as in that is the general pull up on an GPIO. The 32f103 is unique in its USB module, it is the odd one in the family in terms of its register addressing etc... Not a big problem for you though. There is no USB hardware pull up inside the micro.As for Fet/Transistor/GPIO - you don't want the data line pulled down. A fet guarantees that it can only be pulled up to 3.3v. A gpio not floating will pull the line down. Upon reset all GPIO's are floating so not a big problem. Just set the data before direction and you'll be ok with GPIO driven.I implement an emulated file system on chip and allow firmware updates to be written directly to the STM's ROM. I split it in two halves, once the lower half is written it checks a checksum and if all is well, it will run code from RAM to erase the upper half and re-program. Then it jumps to the reset vector.

author: neslekkim
author_rank: Super Contributor
timestamp: June 15, 2015, 07:29:17 am
content: What about looking at these schematics?http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259875

author: atferrari
author_rank: Frequent Contributor
timestamp: June 15, 2015, 09:11:48 am
content: Quote from: BennVenn on June 15, 2015, 02:52:15 amHola BennVenn,Finally I hear of someone who took the pain and succeeded.I tried to program a 18F micro, following the code posted in a interesting thread in the Microchip forum but I couldn't follow the whole process in spite of reading the mother document about USB.Is it any chance that you could post any flow diagram (if you have one of course) for me to have a fresh guide on that? I know it is hard work but I find that appealing.I will appreciate any additional comments from you if the OP does not consider this derailing his thread. Gracias.I am not C conversant, by the way.

author: jnz
author_rank: Frequent Contributor
timestamp: June 15, 2015, 02:27:03 pm
content: Quote from: neslekkim on June 15, 2015, 07:29:17 amAnd what is it you like about that one? It's using an NPN transistor to load up the pull-up but also the 5v rail which I don't have normally without USB connection. I'm only guessing they are using what looks like 4V to get full turn on and shut off on the transistor.I'm not sure in what way this is better than a GPIO pull-up. Except for the idea that it can't be a pull down accidentally.Plus I am under the impression the STLink portion of that board is an STM32F4 and the F1 part I am using does need the 22ohm inline resistors.

author: BennVenn
author_rank: Regular Contributor
timestamp: June 16, 2015, 01:10:36 am
content: Quote from: atferrari on June 15, 2015, 09:11:48 amHi atferrari,I hadn't found any information on an asm implementation of a USB 'driver' for an ARM. Finding anyone that codes an ARM in asm is rare, most of the comments I received were 'Just use C' or 'We can't help you if you are not using the supplied library' etc... I don't consider myself to be that confident in C so I went ahead and did it all in assembly.I migrated from an AVR background so not only was there the learning curve of the ARM (NVIC, byte aligned addressing, user mode etc) but I had no idea on how USB actually worked. If there is one thing that really made all this possible it would be my USBee logic analyser (I paid just under $400 for mine, I’ve since seen Chinese clones on ebay that use the same hardware/software suit for $15...)The USBee software has a USB decoder. It is pretty rough but has enough features to strip away the junk and leave you with the data going back and forward. I started playing with the hardware registers in the ARM until I was confident I could get the peripheral to do what I want (Respond to the host, pass data). From there it was simply reading through the USB spec sheets to get the lowest software layer OK, then build up with HID, MSC, SCSI etc...Get yourself an old cheap USB mouse to interrogate the protocol. Find out what each of the packets mean, how the PC enumerates the device and then replicate that. Once you have the template coded, its is as simple as changing some of the information. MSC is more complex and relies on a state machine as there are different modes etc.. Transparent SCSI is a bit of code to bridge the mass storage to the MSC driver and handles Read-Modify-Write etc...If you want to know more send me an email and we can nut it out. I don't program with flow charts or anything like that. I just write what I think will work and sometimes it does :-)jnz: What dev board do you have?

author: jnz
author_rank: Frequent Contributor
timestamp: June 16, 2015, 04:30:04 am
content: Quote from: BennVenn on June 16, 2015, 01:10:36 amOmilex P107, Nucleo F1, DISCO F2, DISCO F4, Keil's big F2 board I think it's F2... I don't even remember. It was worth it to buy a handful and not get hung up on certain things like is it just this chip, or this board, etc. I didn't mess around on tools, even picked up a Segger Ultra because every day I'm messing with tools or compiler or bugs is a day I'm behind on getting something out the door. Gotta spend money if you want to make money.As to the original question, I forgot my chip didn't have USB OTG, so I got my ID pin back, and was able to cut out a lot of the complicated power switching from Host to Device. Decided that I found enough examples using a GPIO as the D+ pullup that I'll give it a try. If I make a mistake on the PCB it'll only be $100 error or so. I saw some with a single NPN using the 5VBus and another was using a two transistors for some reason, I think some people like to make things complicated on purpose... like lunatics that code in assembly by choice

author: atferrari
author_rank: Frequent Contributor
timestamp: June 20, 2015, 02:50:18 pm
content: Hola B en VennPM sent already.