Hi,

I follow the instruction concerning the installation of Windows serial configuration from this page: http://mbed.org/handbook/Windows-serial-configuration But when I run the: mbedWinSerial_16466.exe The PC (Windows7) display a window that tell me: The drive could not be installed. No mbed Microcontrollers were found.

Some one have some suggestion ?

Enrico M.

Hi Enrico,

Here is what worked for me:

1. Install the latest ST-Link Driver: https://mbed.org/teams/st/wiki/ST-Link-Driver This driver adds the Virtual COM port necessary for serial communication with your PC. When you plug in your board you will see a new COM port in the Device Manager:

2. add the serial code to your project

NOTE: I just tried with the regular "printf" function and that seems to work too, so you might not need to use pc.printf ... e.g. printf("LED is ON");

3. use a Terminal Program to connect to the "Virtual COM Port" from Step one (e.g COM16) at 9600 baud to see the debug output. I use PUTTY, but TeraTerm or any other terminal program should work (http://mbed.org/handbook/Terminals):

Hope that works for you!

Hi Mike, Thank you for the explanation. I resolved my problem an hour ago. I simply turned off and then turned on my PC and "magically" it's work !!! My PC is a company PC and normally I put it in sleep mode, there was probably some configuration or antivirus that blocked the installation.

In any case, thanks for your help. Enrico M.

I've installed all drivers, and can get Serial communication working in many cases. At the same time, uploading a new program seems to 'break' the connection in some fashion. In particular, if I create a new project with the default "printf" template, I can open something like puTTY or TeraTerm, and nicely see the output. If I then upload the project again (without disconnecting the terminal), I find that the terminal, while "thinking" it's still connected, doesn't actually see any new incoming bytes.

I believe that it has something to do with the USB reinitialization as the new program is started, but frankly, it's incredibly frustrating. My 'usual' mbed development behaviour is to use Serial over USB to get debug, status, and other messages, then make changes/improvements to the code, then upload again, and watch the next run.

Currently, I have to unplug the mbed, and restart my terminal client every time I want to upload a new file - it's killing my productivity!

Does anyone else have this behaviour, and more importantly, is there a simple workaround? (I've tried putting a 3 second wait at the beginning of main to give the USB a chance to init before sending on it, for example, to no avail).

That is in principle the case with all the mbeds after the two original ones. Why? No idea.

But while I don't have the Nucleo ones, what works for me for all others in Teraterm is:

• Alt+I (kill current connection)
• Alt+N -> [Enter] (Make new one, for me it then directly selects the correct one, so i can press enter immediatly)
• Alt+B (like usual, send reset command)

Okay better if first two steps aren't required, but it takes barely time.

Actually, I know why - the first two have a secondary chip (on the bottom) that actually handles the USB communication, including the MSD, upload/reset, and converts the LPC1768's UART to a USB connection. All others omit the chip for cost savings, and instead do the USB work on the 'main' mbed chip itself. This means that when it needs to reboot, the USB connection is temporarily interrupted and restarted, which is why it disappears and reappears from the device manager and such.

I was just hoping there was a better solution. Still, your keyboard shortcuts will drastically improve things on my end, so thanks very much. That's the kind of 'trick' I needed.

Thats actually only the case for the LPC11u24 from seeeduino, and similar ones which use the USB bootloader of those LPC chips. All other boards still use a seperate interface IC, only no external flash memory to save the binary on like the initial two mbeds used. But there is no bootloader on the main IC itself.

I agree the original situation was best, still for example LocalFileSystem was also nice to have and really handy, the method of using a debugging interface to access them is not ideal. So then they would have that flash memory only to store binaries before loading them. But why exactly it needs to reset? No idea.

Still with those shortcuts it isn't that big of a problem.

My pc isn't able to receive any data. Not any terminal can receive data, but data sent arrives fine. (logic analyzer checked) Also, the chip sends the data perfectly of this example. https://mbed.org/teams/ST/code/Nucleo_printf/ But it is incapable of getting to any application on the pc

Sometimes the port is listed in devices manager, but no terminal can open it.

Did I do something wrong somewhere, or is the ST-Link serial port feature not finished yet?

I have also noticed some instability issues after downloading a new compiled binary. Best option is: quit the terminal program, disconnect the USB cable and it plug it back in, start the terminal once the COM port has shown up again in device manager. Not pretty, but it seems to work. I hope this will get better with an updated version on the ST-Link interface. Other solutions given in answers above dont work reliably for me.

I have had the same problems with STLink. It's even worse under Linux - no serial communication at all. I ended up fixing USBDevice library support for F401RE and using USBSerial library (https://mbed.org/users/tolaipner/code/USBDevice/wiki/Homepage).

Hi all

Have a look at latest STLink firmware upgrade (https://mbed.org/teams/ST/wiki/Nucleo-Firmware).

You'll see there was a change, that is keeping open the Com port, even if an STM32 new flashing did occur :).

SeaFood