chipKIT® Development Platform

Inspired by Arduino™

Bootloader won't timeout if something is attached to RX/TX

Created Sun, 26 Feb 2012 13:19:24 +0000 by jamarju


Sun, 26 Feb 2012 13:19:24 +0000

I have a GPS connected to the RX/TX pins of a Uno32. If the GPS boots along with the Uno32 and starts sending NMEA sentences right away the bootloader gets stuck forever, probably waiting for flash commands.

The bootloader should timeout after enough time has passed without receiving proper stk500 commands, like the ARduino does.

Any fix for this, and how?



Sun, 26 Feb 2012 19:03:55 +0000

Could you use serial 1 on pins 39 / 40 . I have annoyance in the other direction , uploading with active serial signals on 0 /1 MPIDE gets confused i have to disconnect usb. so I had to install switches , is there any way round this ?


Fri, 23 Mar 2012 00:10:06 +0000

Ok, answering myself about a month later. I cloned the Uno32 bootloader repository, bought a Pickit3 and set out to fix this myself...

I put a hack together whereby the bootloader state machine jumps to app code if it spends to much time in ST_START since ST_PROCESS was last visited, which essentially means the bootloader is receiving garbage and we shouldn't expect stk500v2 commands anytime soon.

I managed to overcome a few issues by which the bootloader won't compile under the new C32 v2.02 by just reverting back to v1.11-A, which is the one my original uno32 bootloader was compiled with.

Finally I flashed the bootloader, but then, when I tried to upload from Mpide... BAM!!! I've got the infamous "verification error, first mismatch at byte 0x0180" error.

I read somewhere else in the forum about this being fixed in the latest bootloader. Is it possible that the github version is not up to date?



Fri, 23 Mar 2012 01:22:04 +0000

Ok, anyway, on with the monologue... I've fixed everything now: both the verification error at 0x180 and the gps/bootloader conflicts are gone.

My fork fixing those two issues is at:


If you want to jump straight to the binaries, go and grab the .hex file from:


And for the gory details, my changes are in pic32bootloader.c:


My bootloader is labeled "MLS/jamarju" and version is bumped up to 1.2 so that you can tell them apart from the monitor (pressing '!' during boot, then '?' as explained elsewhere).

Hope it helps someone.