CDC serial disabled via change to USBcore.h (oops).

Greetings;

Commented out a few lines of core code to disable RECOGNITION as CDC serial device. Actual result, disabled CDC serial functionality. Unable to upload either via USB or Arduino as ISP. Using Pro Micro (32u4), Uno as ISP.

Error messages:

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14 // Huh?

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x01

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10

avrdude: initialization failed, rc=-1

Double check connections and try again, or use -F to override this check. // Please explain use of -F?

the selected serial port avrdude: stk500_disable(): unknown response=0x12 does not exist or your board is not connected.

My understandings of bootloaders, corefiles, and fuses are this: from experience, certain core files dictate USB and serial protocols, fuses are like "should-be-permanent-firmware" or something, and bootloader "etches" this all onto a new or empty chip? Mostly over my head.

I am willing to scrap this board and call it experience, but if there's something I can learn besides "don't eff with core files", that would be great.

If someone could explain those error messages to me, it'd be greatly appreciated.

Thanks a lot;

Bill Hawes.

Hossifer: Unable to upload either via USB or Arduino as ISP. Using Pro Micro (32u4), Uno as ISP.

For now, let's try to get it working without the Arduino as ISP. I'll provide instructions below.

Hossifer: certain core files dictate USB and serial protocols

Yes.

Hossifer: fuses are like "should-be-permanent-firmware" or something

First of all, you don't need to worry about fuses for the sake of dealing with your current problem.

However, you might be interested to know more about fuses just for the sake of learning: Fuses are used to configure the microcontroller. There are a number of different things that are configured via fuses, including:

  • Clock source
  • Clock frequency
  • Amount of flash memory reserved for the bootloader
  • Brown-out detection voltage level

Regarding "should-be-permanent-firmware", there are a couple of fuses that could make it difficult to reprogram the chip (RSTDISBL, SPIEN), but that's certainly not all fuses are used for.

You can get all the nitty gritty details about fuses from the datasheet. There is also a neat online "fuse calculator" tool that you can use to check the results of fuse values as well as to calculate the fuse values for a desired configuration. Here it is showing the fuse values on your Pro Micro: http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega32u4&LOW=FF&HIGH=D8&EXTENDED=CB&LOCKBIT=2F

Hossifer: bootloader "etches" this all onto a new or empty chip

The bootloader is some code that is stored in a special section of the flash memory on the ATmega32U4 microcontroller called the boot section. When you power on or reset the microcontroller, the code in the boot section runs first. The bootloader on your Pro Micro creates a CDC serial port and then waits a little while to see if the data of a sketch upload starts arriving over that port from the Arduino IDE (actually the avrdude tool the Arduino IDE uses for uploads). If so, it will save that data to the flash memory outside the boot section (so it doesn't overwrite itself). If no upload data arrives after several seconds, the bootloader times out. Whether the upload finishes, or the bootloader times out, it then exits the bootloader code and your sketch code then runs.

So the key to a successful upload is for the microcontroller to reset and activate the bootloader before the upload starts, but not too early, otherwise the bootloader will have timed out and exited before the upload even starts. On the Pro Micro, the way the Arduino IDE triggers that upload is by opening a 1200 baud connection to the serial port provided by the USB core code running in the background of your sketch code. The core code sees that 1200 baud connection as a signal to reset the microcontroller to activate the bootloader so an upload can happen. If you mess up that core USB code, the Arduino can't receive that signal and so the normal upload process doesn't work. In this case, the solution is to manually reset your Pro Micro at just the right time during the upload:

Since your Pro Micro doesn't have a reset button, you'll need to connect a wire to the reset pin and then prepare to connect to and then disconnect that wire wire from the GND pin to trigger the reset. The way to get the timing right is to start an upload and then watch the black console window at the bottom of the Arduino IDE window. As soon as you see something like this:

Sketch uses 444 bytes (1%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

Now connect and disconnect the wire between the GND and reset pin.

If you first fix the USB core code and then do the manual reset process once, you should then be able to go back to doing uploads regularly.