COM port (18) is in use by another process

Created Mon, 09 Jan 2012 11:53:48 +0000 by randomrichard

randomrichard

Mon, 09 Jan 2012 11:53:48 +0000

Hello. I have recently obtained a Max32 with a couple of shields (I/O and, network). I did some testing with a PICkit-3 and v8 MPLAB IDE and everything went well. However, I cannot get the Max32 to blink or do anything else with the Mpide, uploaded this week. The sketch compiles OK but when I try to upload the process freezes and I eventually get an error message telling me that the COM port (18) is in use by another process, which I should stop before using it for the Max32. There is no other process. However, my Win7 64bit machine shows two "processes" operating in the FT232R USB device that represents the Max32. These are, under the hardware window; "USB serial convertor", and "USB serial port (COM18)". Is this the source of my problem and , if so, how do I cure it? The option to reinstall the driver is greyed out. Richard

Jacob Christ

Tue, 17 Jan 2012 00:19:49 +0000

What happens if you kill the processes or re-boot? Sometimes processes that open a serial port become zombies and don't release the resource.

Jacob

redarmy1

Thu, 02 Feb 2012 18:20:31 +0000

Hi

I had this problem and was stuck for weeks i used a pickit debugger to re-flash the bootloader and it has been fine since

KeithV

Wed, 14 Mar 2012 14:59:56 +0000

Hi I had this problem and was stuck for weeks i used a pickit debugger to re-flash the bootloader and it has been fine since

As Jacob said, something is holding the resource (com port). This can happen if something goes wrong with an upload from MPIDE. Avrdude is a seperate application that runs in the background from MPIDE. If for some reason (and it happens) that avrdude gets into a timeout loop holding the com port it will appear that the com port is in use even if you restart MPIDE. Just because you restarted MPIDE does not mean avrdude was restarted. The way I solve this is to start task manager and manually kill the avrdude background process. If that fails, sometimes unplugging and replugging in the USB cable will work, and if that fails, I reboot the computer. You should not have to reflash the bootloader, just power down the board.

Worst case should a partial program get programmed onto the board and the partial programming has trashed the UART and somehow prevents MPIDE from doing a reset (which is may actually be impossible) you can hold the reset button down on the board and start an upload from MPIDE, once you see that MPIDE is attempting to upload to the board release the reset button and MPIDE should be able to freshly install a new program through the bootloader. However, this is an extremely rare condition.

Of course, when all else seems to fail, reprograming the bootloader is an option, and in the end, whatever works... well it works.