chipKIT® Development Platform

Inspired by Arduino™

Unable to lock serial port for board reset

Created Sat, 26 Sep 2015 11:42:01 +0000 by YOBE.

YOBE.

Sat, 26 Sep 2015 11:42:01 +0000

Hi,

I have been so stupid to load this program to my Chipkit Uno32. Now it seems I cant upload software anymore..... Probably its in an loop that causes this error message:

Port name - COM4; Method name - setEventsMask(); Exception type - Can't set mask. Unable to lock serial port for board reset

Can somebody please help me to explain how to solve.

void loop(){

// Now color 50% screen
digitalWrite(tft_RS, LOW);  // command mode
SPI.transfer(tft_RAMWR);   // Prepare TFT for sending data to RAM until a new command is given

digitalWrite(tft_RS, HIGH); // Data mode. And send each time 2 bytes for the color of 1 pixel (16 bits)
for (int i=0; i==1000; i++){
	
	 SPI.transfer(ColorH);
	 SPI.transfer(ColorL);
	 Serial.print(i);
}
loop();

}

EmbeddedMan

Sat, 26 Sep 2015 11:55:00 +0000

YOBE,

What platform are you running on, and what IDE are you using?

I don't see anything wrong with the sketch you've loaded. I don't see any why for a sketch to produce the error you are seeing. So you weren't stupid at all.

To me, it sounds like there is some other application on your PC that is using the COM port that the UNO32 board has been assigned. I'd try rebooting your PC, and then try reprogramming the UNO32 again, and see if you get the same error.

*Brian

YOBE.

Sat, 26 Sep 2015 12:42:59 +0000

Hello,

I am using the UECIDE platform.

But to my knowledge, the last part of the software is a pur "loop". Now this creates a situation that probably the UECIDE can not connect to the micro controller anymore.

Port name - COM4; Method name - setEventsMask(); Exception type - Can't set mask.

"Can't set mask" is linked to this I think.....

I can't upload new programs anymore.

majenko

Sat, 26 Sep 2015 13:22:52 +0000

Which version of UECIDE are you using? There is no way a sketch can stop you uploading code - the board is physically reset by the IDE before programming and the bootloader program is run instead of your sketch. Your sketch is never running at that point.

I haven't seen that message before with UECIDE, although I rarely (if ever) use Windows.

YOBE.

Sat, 26 Sep 2015 13:30:26 +0000

Hi,

UCEIDE 0.8.7j And also tried with version another version 0.8.7z36 on another PC

Are you sure, the 'loop" function isnt causing the UCEIDE to interfere? The "set mask" issue makes me wonder

YOBE.

Sat, 26 Sep 2015 13:38:10 +0000

I have no clue what is going wrong with UCEIDE, but when opening my old MPIDE (20131118), I am able to upload. Even after uploading a "Blink" program (with MPIDE), UCEIDE keeps generating the same error even with the "Blink" program.

Pitty, I was quite enjoying the UCEIDE environment....... :( :( :( :(

majenko

Sat, 26 Sep 2015 13:40:20 +0000

The error has nothing to do with your sketch. It's purely to do with the interaction between UECIDE and the driver installed for your board's COM port.

Try using the current beta version of UECIDE since he serial system has been somewhat re-written since the old 0.8.7j version.

majenko

Sat, 26 Sep 2015 13:41:23 +0000

Also make sure you don't have anything else trying to talk to the serial port on your computer, like UECIDE's serial terminal plugin.

YOBE.

Sat, 26 Sep 2015 13:47:58 +0000

Thanks Majenko for the feedback. Just restarted my PC and reinstalled my original UECIDE version and now its running again.

Initially I searched the internet and I saw lots of issues with re-installing bootloaders because of "loping" issues with boards. But seems I got worried to fast.

You advice upgrading to the beta version of UECIDE? Or no major differences....

PS: only strange I had it on both PC's with UECIDE..... :?

majenko

Sat, 26 Sep 2015 13:54:54 +0000

There are huge changes in the beta version, including a completely re-vamped plugin system. Not all the boards and cores are ported over to the new system yet, so if you use some of the stranger systems then you shouldn't upgrade. All the chipKIT boards and Arduino boards are supported fine.

It does mean that you would have to delete and reinstall all your existing UECIDE cores and things since there are a few incompatibilities between the old and new systems.

FredCailloux

Sat, 13 Feb 2016 03:21:08 +0000

I just tried to upload my new LS7366 Class and implementation sketch to my CEREBOT MX7cK board and I got the same error!

Compiling done. Bla Bla Bla No target found. Port name - COM4; Method name - openPort(); Exception type - Port busy. Unable to lock serial port for board reset

There are no other applications on my computer that is using any COM port and I have UECIDE version 0.8.7z36 Build 565 . I did check that the board is properly connected to COM4 and the computer is reacting correctly when I disconnect the USB cable and reconnect it, the COM4 port is re-instantiating. I hope I will not have to reinstall UECIDE again. It use to work fine before. Surprise Surprise. Funny thing is, my proMX7 is still working fine with the previous sketch and after the unsuccessful upload it restart with the previous code. What's next ?

FredCailloux

Sat, 13 Feb 2016 04:00:14 +0000

I also tried to transpose my sketch to MPIDE. I can compile the sketch OK but cannot Upload to the MX7cK board, just like with UECIDE. I really need to find a solution to this problem.

Thanks for any help.

majenko

Sat, 13 Feb 2016 08:46:56 +0000

I'm sorry, but when it comes to Windows I can be of no help. Which USB port are you using on the MX7cK?

Sent from my SM-T555 using Tapatalk

FredCailloux

Sat, 13 Feb 2016 17:19:50 +0000

Turned everything OFF yesterday. Tried it back today and now I can work just as before! Surprisingly, I did try to reset both my board and computer yesterday and didn't get any result. Now, after one night, I am back on track. go figure ?

I am using COM4 and as far as I could see, nothing else on my computer is using the COM4 port, or any other ports for that matter. The port was showing a driver that was working fine according to Windows7.

So, I guess we will never have an answer on this one, unless the problem reoccur and that I end-up finding the root cause of the situation. Until then, I'll keep programming.

Thanks for your support, anyway

FredCailloux

Sat, 13 Feb 2016 21:18:02 +0000

Upload failing came back again. This time with a different error:

Memory usage C:\Prog\IDE_UEC_MP150\UECIDE\compilers\pic32-tools/bin/pic32-size ...\PmodAD5voltMeter\build/PmodAD5voltMeter.elf • Program size: 17772 bytes • Memory size: 4672 bytes • Compilation took 1.899 seconds Uploading firmware... • Resetting board... • Uploading... C:.../pic32prog -d \.\COM4 -p PmodAD5voltMeter.hex - Programmer for Microchip PIC32 microcontrollers, Version 1.113:114M No target found. • Resetting board... Upload Failed

I can conclude for sure that the COM4 port is talking to the board because the uControler is getting a Reset and restart the present program. Is it possible that the intermittent problem is caused by some tricky code line that I previously put in the MX7cK ? Is there a proper procedure or sequence by which I should turn ON Computer, Connect the USB, Turn ON the board ? Is the fact that I have programmed my board approximately 25 times so far, that I have exceeded the maximum time the board could be programmed ? I really need to find a solution to this problem.

FredCailloux

Sat, 13 Feb 2016 23:37:58 +0000

Question: Is it possible that the MX7cK keep running and at the moment of uploading a new code, if it happen that I have a board that draw some 200mA from JA (8 digits LED board that is) is it possible that the upload momentarily draw more current, hence, provoking a short voltage drop on the 3.3V enough to trigger the uController reset, hence, wrecking havoc the upload procedure and generating this kind of error ? I took all outside ( small I must say ) current sink from all pMod jacks and was instantly successful at uploading a new code. Meaning my board is not defective and my COM4 USB channel is running properly. So then the question to ask is: How much more current the MX7cK draw while receiving an uploading new code ? Any idea anyone ?

majenko

Sun, 14 Feb 2016 10:41:14 +0000

I find it hard to believe that you would have brownouts only while uploading code and not the rest of the time.

What is it you have plugged in and where to? It is more likely that what you have plugged in is interfering with the UART connection to the PC in mych the same was as interfacting to pins 0 and 1 on an Arduino does.

Sent from my SM-T555 using Tapatalk

FredCailloux

Mon, 15 Feb 2016 16:06:48 +0000

I am using an 8 digits LED display called TM1638 (sorry, cannot upload the datasheet. I get an error when trying to attach the pdf file). It is using a Class called TM1638. I had it run on the 3.3V line, hence, drawing it's supply current from the little VCC3V3 PWM regulator on the MX7cK. That was too much for the 3.3V I guess. Since I have it connected to the VCC5V0 I have no more problem. I check the theory again and bang! no more upload and chip reset. I can now confirm with 99% certainty that it was my TM1638 plugged into VCC3V3 that is interfering with the board regulator having somehow an impact on the uploading procedure. Since my immediate goal is to get this LS7366 chip working with DSPI class I will not investigate further this TM1638 problem for some time now (or maybe never) because I have no more problem with uploading my code.

Thank you for your support. And I hope to have added a little piece of knowledge in this forum for the next person who get a similar uploading error. Check your current consumption on the VCC3V3 regulator. It may be too high. I am not saying that this is the only cause for such error but in my case it sure was.