I opened the RIDE7 Virtual COM Port project in the USB Developer Kit UM0424, built, and ran on my STM32F103B duaghter board in my Rlink V3.3 motherboard. The processor is STM32F103RBT6.
It is connected to the PC. The firmware seems to be running. THe red Run LED stays on, and up to the USB_Init() line in main, it stops at breakpoints. It runs all the way to the last line of USB_Init() and never gets past that point.
When I unplug and reconnect the USB cable from the daughterboard to the PC, the Device Manager screen acts appropriately: under "Universal Serial Bus Controllers," the listed "Unknown Device" disappears. When I reconnect, the "Unknown Device" reappears. With an oscilloscope I can see traffic on the USB line when I connect.
Using a breakpoint, I see that the ISR USB_LP_CAN_RX0_IRQHandler() never runs.
Of course, I never see the New Hardware dialog on the PC either.
The only way I can get the firmware to run at all is to set Properties/Advanced ARM Options/ Processor/Device = STM32F103RBT (no surprise there), and Boot mode = RAM. With Boot mode = Flash, the red Run light flashes briefly and goes off.
I have only been on this a few days. Can anyone suggest which of these documents might be most helpful first, and maybe even one or two things I am doing wrong?
Did you try to only program the device and not debug it? Debugging can cause problems using USB apps because the host PC usb controller can loose synchronization with the stopped mcu. Go to the RLink Advanced Options, uncheck Debug and see what happens...
Thank you for the reply, Lionel. I unchecked the Debug box in Virtual_COM_Port/Properties/Cortex RLink/ Advanced Options. On that same dialog I clicked "Write target FLASH Now!" and located Virtual_COM_Port.hex in the ...\RIDE\obj folder. The program loaded successfully. I tried various ways of starting the program and can only assume that it is running.
I am getting the same result.
I put another daughterboard into the RIDE and tried again. Same result.
I believe that my PC is sensing the disconnecting and re-connecting of the cable to the daughterboard, because the Device Manager device list changes as expected each time. However, it always says "Unknown Device" in the "Universal Serial Bus Controllers" list when I re-connect, and it never displays the New Hardware Found dialog.
With the oscilloscope I can see a pattern matching Figure 7-32 "Bit Stuffing" in the USB 2.0 spec, that is, the Sync Pattern, followed by other data. My PC operates ok with other USB devices.
From all this I infer that the PC is sensing the voltage change caused by connecting the cable, and the PC is transmitting as it should, but the STM32 is doing nothing.
The other day I loaded and ran another demo on the Reva with this daughterboard. The demo was supposed to turn lights on and off. It worked, that is, lights went on and off.
I noticed while debugging that when the PC transmitted USB data, the USB interrupt didn't happen. I know that because I had a breakpoint at the interrupt handler.
Is this firmware failing to enable the interrupt? I don't know because I haven't figured out yet how to enable interrupts with STM32 yet or how to know if an interrupt is enabled by looking at registers.
I tried the Virtual COM port application (USB2COMn) on my STM32 Primer yesterday. At the first connection I directed the XP to the requested driver, I got some error messages, but at the second connection the driver installation seemed to be successfull (despite of the error messages) because the application worked fine. The Tx counter was incrementing and I received blocks of cca 250 identical characters on terminal emulator. Pressing keys on the keyboard incremented the Rx counter.
Yes Metos we could also make the example work when we installed the driver purchased with the application. It stands in this folder: STM32F10xUSBLib\USBLib\demos\Virtual_COM_Port\Software Driver.
About the problem Bugbuster meets when she debug:
"It is connected to the PC. The firmware seems to be running. THe red Run LED stays on, and up to the USB_Init() line in main, it stops at breakpoints. It runs all the way to the last line of USB_Init() and never gets past that point."
It seems that the program is waiting the usb to be connected and this is why it stays in this loop For instance if you start debug then unplug and plug the usb it goes through the USB_Init function And everything works fine It was the way the application was written that might requires to plug after microcontroller is running. Plase let us know if it helps
Also please note when you use others USB in debug mode it could have some unexpected behaviour due to the phases where the CPU of the targets is stopped by the RLink!
Thank you for replying and contributing to my thread.
I have disconnected and reconnected the USB cable as suggested, with no effect, except that the PC Device Manager window does indicate that an "Unknown Device" has been connected, nothing more.
I have so far identified two issues with the firmware:
First, the firmware references GPIO PD.09, which does not exist on this chip, the STM32F103RBT. Second, the Set_USBClock() function has no code in it.
For me, these two facts cast doubt on the validity of this firmware.
I am working my way through the technical reference manual to figure out what has to happen to make this firmware work.
Does anyone know where this firmware came from and on what platform it has been tested?
Are you guys using the Reva STM32103B evaluation board with the USB Developer Kit firmware available on the STM32 document page?
Or are you using the STM32-Primer device?
The Virtual COM Port demo and the DFU demo definitely do not work on the Reva device, no doubt about it. I have two daughterboards, and I know how to connect a USB device, and these devices do not work with this firmware. I have written detailed descriptions in previous posts both here and at STM32 forum at st.com.
The Reva device uses the 64-pin STM32F103RBT. Does the STM32 Primer have the 100-pin version of the STM32F103RBT? Maybe this is why the firmware references GPIOD PD.09. The Reva doesn't have that pin. Does the STM32 Primer?
We tried with STM32F103 daughter board and used a REva v3.3 The chip is STM32F103RBT6 We download directly from ST website the firmware First we had the same problem as you had: the program could not go out of th USB_Init function
After that we installed the correct driver and start debugging The program never goes through USB_Init neither until when we unplugged and plugged the USB again Then it goes through that function and when we opened an hyperterminal on the PC: we were able to send data through the COM3 as we could see the counting value increasing in the program
These are the steps I followed with RIDE7 and my Rlink V3.3/ REvaV3.3 motherboard.
Deleted the existing copy of the demo downloads from my hard drive.
Downloaded um0424.zip from http://www.st.com/mcu/familiesdocs-110.html#Firmware and unzipped it into my chosen folder, using the folder structure contained in the zip file, so that STM32F10xUSBlib is a subfolder intact with all downloaded contents.
Copied ..\STM32F10xUSBLib\USBLib\demos\Virtual_COM_Port\Software_Driver\stmcdc.inf to c:\Windows\INF.
Connected the USB cable to the Rlink. This is the only power source.
Disconnected the mini USB connector from the daughterboard.
In RIDE7, opened project ..\STM32F10xUSBLib\USBLib\demos\Virtual_COM_Port\project\RIDE\Virtual_COM_Port.rprj.
Opened the Virtual_COM_Port project Properties window, selected Cortex Rlink/Advanced Options, and checked "Debug." Selected Advanced ARM Options/Processor and selected Device=STM32F103RBT6 and Boot mode=RAM.
Selected Project/Clean Project.
Selected Project/Build Project.
Opened the debugger, the code loaded successfully.
Opened the Control Panel System/Hardware/Device Manager, expanded "Universal Serial Bus controllers" list.
Selected the green Run button. The RUN red LED on the motherboard lit and stayed on.
Connected the USB mini-connector on the daughterboard.
Observed "USB Device Not Recognized" on my PC system tray.
Observed new item "Unknown Device" on the Device Manager "Universal Serial Bus controllers" list. The Device Instance Id on the Details tab is "USB/VID_0000&PID_0000\5&151D929&0&1".
This is the procedure I followed a week ago when I started posting on the forum. Since then I noticed that the USB interrupt handlers do not run at all, which I determined by setting a breakpoint. I observed data on the connector, both pins, presumably transmitted by the PC. The data exactly resembles what I have seen in the USB 2.0 spec.
We have two STM32F103B daughterboards. Both exhibit the same behavior.
I did successfully run two other demo programs: a USART1 demo and one that flashes LEDs on and off in a pattern.
I was able to confirm presence of a signal by probing a via near pin 45. Pin 44 is too difficult to probe, but I do see well-formed data at the resistor connected to pin 44.
This Windows XP PC does perform correctly with two other USB Virtual Serial Port implementations: the Keyspan serial adapter and the Silicon Labs CP2101 USB Serial Bridge.
As noted in another thread, RCC_CR PLL_ON never displays, no matter what, in the Debug Explorer window. Even right after running line 81 in Hw_config.c, RCC_DR indicates PLL_OFF. The function uses bit banding. That doesn't set the bit, and neither does a direct write, at least according to the Debug Explorer.
The PC responds exactly the same as described above after erasing all the code, disconnecting the mini USB connector, and re-connecting it. In other words, without any firmware at all, I get the same result.
Copied ..\STM32F10xUSBLib\USBLib\demos\Virtual_COM_Port\Software_Driver\stmcdc.inf to c:\Windows\INF.
Are you sure this works correctly? AFAIK, it is not the way to go. You should right-click on the .inf file and select "Install". Does it work better ?
Apart from that, you should not see any "unknown device" in the USB list if you erased the firmware. The USB controller is inactive by default. If you happen to see an unknown device, it probably means you did not erase your device correctly.
I would suggest to forget about the RAM boot mode for now. Set your daugther-board boot mode to Flash, and in the debugger options as well. Then erase your device again, try again to see if an unkown device appears. Eventually, try to program the Flash with the application and reset the device or start it in debug mode. Does it work in that case ?
I right-clicked on stmcdc.inf and selected "Install." There was no dialog, just a brief display of the hourglass cursor.
I changed from RAM to flash and checked that STM32F103RBT was selected.
I disconnected the mini USB cable.
I opened the Cortex Rlink/Advanced Options, unchecked "Debug,", then "Erase target now!" then "Write target FLASH now!" I selected the Virtual_COM_Port.hex from ...\RIDE\obj, checked the modify date, and selected it. It loaded ok. I cycled power.
I connected the mini USB cable and got the same result. I re-tested our device with the Silicon Labs CP2102 USB-Serial bridge chip, also a virtual com port. It still enumerates and works ok.
We have two of the red and white installation CDs here. They both are labeled "STM32_071005." Does that mean they are identical? Could one have wrong data on it?
The Device Manager list always shows this for the Unknown Device Properties/ Device Instance Id when I connect the mini USB cable: USB\VID_0000&PID_0000\5&151D929&0&1 How could I verify that this data was transmitted from the STM32 to the PC host? Could I see this string data in the code?
In the stmcdc.inf file, it shows USB\VID_0483&PID_5740. Isn't that what the system is looking for?
I just tried another cable and got the same result.
In the stmcdc.inf file, it shows USB\VID_0483&PID_5740. Isn't that what the system is looking for?
indeed, these should be the Vendor ID (VID) and Product ID (PID) given by the stm32 firmware. You should see these informations in the descriptors definitions (see usb_desc.c).
I suspect a wrong device reset maybe.
What I suggest first is to let you update your Ride7 installation by downloading the latest version here:
I opened the project c:\Program Files\Raisonance\Ride\Examples\ARM\STM3210B-EVAL\ STM32F10xUSBLib\USBLib\demos\Virtual_COM_Port\Project\RIDE\ Virtual_COM_Port.rprj.
Same settings as before, built and ran in debug mode. Same result using two different cables including a known good one.
I notice that every time I attempt to enumerate while debugging, afterward when I hit the Pause button, The Disassembly View shows me at address 0x20010100 showing all 0xFF, way outside the code region. If I hit the Pause button any other time, it lands inside the code region showing good code. Something is sending us off into the weeds. Could it be something wrong with the stack? Clearly there is something wrong either with the hardware or with the firmware. Could it be the ISR is running but exiting to the wrong place? It looks from here like a classic C bug.
After right-clicking on "Install" with stdcmc.inf, I don't see anything happen, and when I search for the file later, it doesn't show up anywhere where you expect to see drivers. Every other Virtual Com Port driver I've seen (we have done this three times now) puts a .sys file in Drivers folder and an .inf file in the .INF folder.
I don't think there is a proper driver here. That would explain all of this.
The .inf file uses a standard .sys file provided by Windows, and already present on your system, $1. It does not need any additional .sys file.
Again, this driver has always worked very well for me, so I don't think it would be the cause. Maybe you can still check if that file is present on your system anyway...
I do appreciate your continued efforts to help me with this.
There is no usbser.sys on my hard drive, and there is no reference to USB\VID_0483&PID_5740 in my registry. Other Virtual COM Port services on my computer do have registry entries for their respective VIDs and PIDs associated with the appropriate .inf files.
As you know, when a problem is this difficult to solve, it often turns out to be more than one problem. I think we have multiple issues here, all mentioned in previous posts. There is a lot of material here, so I don't expect you to answer all of them at once.
Why am I getting PID=0000 and VID=0000 in the Device Manager Device Id property?
Why, when I click the Pause button, does the debugger stop at an out of range code address after the USB cable has been connected, but at a good address at all other times?
Why does the debugger never stop at any breakpoint in the USB interrupt handlers when the cable is connected?
Is stmcdc.inf supposed to reside in the same INF folder as all the other .inf files in the system? If so, then why is that not happening here after I click "Install?"
With our working Virtual COM Port system from Silicon Labs, the VID and PID appears in the registry associated with the name of the appropriate .inf file. I think that's how the Plug and Play system finds the driver. For the STM32 Virtual COM Port, USB\VID_0483&PID_5740 does not appear in my registry, even though I did click "Install" on stmcdc.inf. Why?
If usbser.sys were missing, then wouldn't I get a "New Hardware Found" dialog when I connect the USB cable?
That's quite a lot for one post. I'll appreciate anything you can do to shed light on these questions. I will cooperate in any and all efforts to get this system working.
Did the people struggling with this problem eventually find answers?
I'm working with the ST DFU suite right now and have gotten it to work, after experiencing some problems whose symptoms were very similar to those described here. The cause was entirely in firmware, specifically in some critical details which are not fully elaborated in UM0424 or in their code examples. If anyone is interested, post here and I'll reply.
Hi!I've got the same problem as bugbuster. I've connected the STM32f103b via USB cable to my laptop, and it was installed as Unknown Device under the Universal Serial Bus controllers Category with USB/VID_0000&PID_0000\5&151D929&0&2 paramethers. Anyone has any idea, why is it happening?
Can anybody tell me, how PMA addresses are translated to?
I'm working in a company as a intern, and my task is to program the STM32 to work as virtual COM. I'm not using an evaluation board (I use a board designed by my company, so the inputs/outputs are connected differently i.e. the disconnect pin is GPIOA 8 not GPIOD 9 etc).
Unknown device with zero VID/PID usualy appears because of three possible reasons: - Windows already detected device with the same VID/PID/RevID and saved it's configuration. Current configuration does not match the saved one so you are geting an error during startup. Change any of VID/PID/RevID (sometimes also helps to change serial number string). - If device appears only after some significant delay (5 sec or more) that means device handled USB reset but failed to send any of it's descriptors (Device Descriptor, Configuration Descriptor or String Descriptors). - If it apperas immediately after connection then the problem is related ot contents of Device or (more probably) Configuration descriptor. Usualy this fault when descriptor size is wrong or configuration TotalLength field is wrong.
Other kind of errors will still allow the device to be correctly detected by host (VID/PID will appear).
I think it's because of the second reason. Does anybody have any idea, how to force the device to send its descriptors? I've tried to implement other stm's demos (custom HID, mass storage). All programs had the same problem - unknown device etc. Maybe it's because of some minor issue, like using different dissconnect pin or different Rx/Tx pin?
A current issue with USB is a bad peripheral frequency, that produces this kind of message ("Unknown device"). Check that the USB of your card is really running at 48 MHz.
I use a 14,7456 MHz oscillator. I think it is causing tne problem. How should I set the sysclk and pll dividers to achieve 48MHz?
EDIT: Nevermind, got it working Ive changed the source of the clock signal from HSE to HSI and added this line
RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_12); then, in set USB clock, changed div5 to div1.
Thanks for all your help !
EDIT2: Well, I've got another question. When I connect my stm32 via usb to my laptop and via COM to another PC, I can't see anything sent from USB to COM in the terminal? When I write something in the terminal to send it from COM to USB, it works fine, but nothing shows up on the terminal when the direction is USB->COM. I've modified the program, so that the USB also acts as echo (sends data_buffor to COM and to itself) and I can clearly see, that the stm32 gets chars written in the terminal. It just doesen't send them to the USART buffor.
The program runs well, the only thing that seems to be not working is this line in st32f10x_usart.c (function void USART_SendData(USART_TypeDef* USARTx, u16 Data))
USARTx->DR = (Data & (u16)0x01FF);
I've checked, the Data are the chars I've entered in the terminal. Any ideas ?
EDIT: Problem solved;) wrong connector on the board. Thanks again for help !
Hi, this is a response to the post from Payatz on 2010-03-12.
Sorry about the delay in responding! Hope this info may (still) be helpful.
My problem with correct enumeration was a direct result of the following:
The application firmware image had been relocated from base address 0x08000000 to base address 0x08003000 in order to leave space for the DFU image to be located at 0x08000000. I took care of this in the linker and in the debugger but since I am still pretty new to ARM etc, I overlooked the not-so-minor detail of the vector tables, which are what actually begins at these addresses. The default is 0x08000000. With a DFU image in place, it is the DFU image's vector table that sits there.
When the DFU image boots into the application firmware image, one of the very first things the application has to do is modify the value in the VTOR (Vector Table Offset Register) of the NVIC (Nested Vectored Interrupt Controller) so that the vector table defined in the application image (and not the one defined in the DFU image) will be used from this point onward. The appropriate statement:
NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000);
which offsets vector table lookup by 0x3000 from its default, was in the application example, but not well documented. The application notes from ST mention that the application image must be relocated, but make no mention of the need for the application to modify the VTOR value. Since I actually didn't even know that the NVIC and VTOR existed, I omitted the necessary statement (knowingly or unknowingly, I don't remember which). Without that, the application will still be running with the vector table of the DFU image. It's a wonder that anything worked at all in that state, but when I corrected this, enumeration began working like it was supposed to.
By the way, I am still waiting for answers from ST on a related topic: how do I implement DFU_DETACH response in my application? This would allow for hands-off firmware updates initiated entirely by the host computer via USB. The only mode I have working requires a manually-initiated hardware reset (or power cycling) while holding down a button to put the device into update mode. The documentation from ST provides some clues as to how to modfy the device application so that the USB host can put it into update mode without manual intervention, but the necessary details are nowhere to be found in either the docs or any of the example projects. Anyone know the answer?
I'm using STM32 in an own designed board and have similar problems with USB enumeration. It appears vid VID&PID 0x0000. I see that just jumps to interrupt routine one at beginning, and no more. Anybody knows if there are any errors in firmware? I observed that STMulus comment this in a reply.
Ive changed the source of the clock signal from HSE to HSI and added this line