Comments: Qwiic Pro Micro USB-C (ATmega32U4) Hookup Guide
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
If you've found an issue with this tutorial content, please send us your feedback!
I used the unbricking procedure to successfully upload a sketch, but the fix does not seem to be permanent. It's unclear from the wording in the FAQ if, once bricked, the double-click-eight-second-window process will always need to be used, or if I should expect a successful sketch upload to permanently unbrick the chip?
One of our customers wrote a simple bash script to work around the double tap timing and automatically load sketches through that method. Unfortunately, it is in an email and we would need to get permission to share it. However, I requested that they make a forum post and I'll try to remember to link it back here if I see it come up in the forum.
Hi,
Hmmm, it depends on your setup. If you accidentally uploaded code with the wrong board selection, you should only need to follow the double-reset procedure once to unbrick with the correct board selection. However, I have seen ATmega32U4's "bricked" causing you to follow the procedure again to upload new code if you are using certain timing registers. I faintly remember a few cases where users had adjusted the timing registers on the Pro Micro and there were upload issues with the timing of USB Communication through CDC.
Does your code use any "watchdog timer, sleep modes, and timer interrupts" with the Qwiic Pro Micro?
No (at least, not as far as I know) -- I was running the example code for the keyboard explorer via the Arduino app 1.8.13 on my macbook air, first with the wrong board, then the right board but wrong voltage. I haven't dug down through the libraries to see if or how any them use the timers. On insertion I see /dev/cu.usbmodemHIDPC1 appear, replaced by /dev/cu.usbmodem14201 when I double-click the reset. It's certainly manageable (and a good reminder to be more careful next time :)
Hmm, the library and example code do not appear to be using any interrupts. It looks like there is some button debouncing but I don't see that causing any issues. Hitting the reset button will cause the board to show up as a different COM port due to the different PIDs for the bootloader and sketch.
It sounds like you were able to unbrick it by re-uploading a sketch using the correct board processor and frequency.
It looks like if the board is powered from RAW, the digital outputs are 3V. If the board is powered from regulated 5V, the digital outputs are 5V. Is that right?
When powered via RAW, the digital outputs are whatever your RAW voltage is. (Absolute maximum for RAW is 6 volts, we don't recommend anything more than 5.5 though.)
When powered by USB, the outputs will be at 5 volts, BUT if you modify the jumper on the bottom of the board, you can convert the digital outputs to 3.3 volts when powered via RAW or USB.
If you have further questions about the board, post on our forums and our technical assistance team can help!
Both you and CF are correct. If the board's RAW pin is connected to your regulated 5V, the I/O pins are 5V. =)