Lilypad arduino loses port while uploading, tx and rx flash rapidly

Hello! I've gotten a bit stuck while working with some Lilypad arduino USBs, and while I have experience troubleshooting arduinos, it's never been problems with the board itself. Additionally for reference, these were by AMX3d.

The current problem is that the boards will run code that was previously uploaded to them, but if I try to upload any code or the barebones example, the TX, RX, and onboard LED flash rapidly at around 7 Hz or so, and the board disconnects itself from the IDE, giving the

Couldn't find a Board on the selected port. Check that you have the correct port selected. If it is correct, try pressing the board's reset button after initiating the upload.

error. Pressing the reset button after this occurs doesn't do much, the lights just start flashing again. However, if the arduino is unplugged from the computer that's powering it, then it resets and the Port shows up normally. Another thing I noticed is that even though the code that was already on the boards continues to run, it looks like it runs 10x slower, with a 1 second delay becoming a 10 second delay.

This happened to my first lilypad but I couldn't hunt down the cause, so I started making it again and this is what the circuit looked like when it broke, the three ovals being LEDs.

I tried uploading the blink sketch, and it worked when the leds were all connected to the Lilypad ground, but after I tried connecting the first LED to pin 9 was when it first occurred. Disconnecting the LED from pin 9 had no effect.


So that's my strange problem I'm having, and I'm not sure what's going on, but I'd appreciate any insights you all might have! While I have more Lilypads, I don't want to keep bricking them if I can avoid it.

Here's a list of other things I've checked/tested:

  • Checked with a multimeter that the LEDs are connected to each other/the Lilypad and make a closed circuit
  • In the IDE the board was set to Lilypad Arduino USB, changing this to Lilypad Arduino or Arduino Uno made no difference
  • Tested multiple micro usb cables in multiple usb ports
  • restarted computer and IDE
  • pressing reset button after starting upload
  • unplugging the arduino as the code compiles and plugging it in to upload

There seem to be a few 'types' of Lilypad; which one do you exactly have?

What are the symbols in the left top of your wiring diagram?

They're Lilypad Arduinos ATmega32u4 with a micro usb slot, based on the v10 judging by the text on the back.

The diagram is a clearer version of what's shown below, those symbols being sequin LEDs. The bottom one with the black got all of the LEDs working, but I can't upload any new code to it. I only got one LED sewn together on the top one before it stopped accepting new code.

Thanks for your reply!

Not sure what sequin LEDs are; do they need series resistors?

Have you tried the double-tap on the reset button? You do that just after the IDE has reported the memory usage.

Which operating system are you using?

I'm running Windows 10. They each have built in 150 ohm resistors, so they should be fine in that regard. I tried double tapping the reset button on the first Lilypad that failed, and while that didn't do anything once the TX and RX lights started flashing, as it just goes back to flashing a bunch once it's been reset and the IDE still doesn't see it on the port.
However, when I held down the reset button while the code compiled and released it when it tried to upload, it would find the port, but then it would throw the following saying the programmer isn't responding:

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean,
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM8
         Using Programmer              : avr109
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

Check what is happening in Windows device manager. I don't have experience with Lilipads, but with a Leonardo the com ports change (due to a reset) when an upload is performed.

  1. Is your board recognised?
  2. Does it change?

I guess that it's a step forward; might be a timing issue :wink: Does the board have an onboard LED? If so, I guess it should fade in and out after you press and release the reset; does that indeed happen?

If you enable verbose output during upload under file -> preferences, you will see something like

Forcing reset using 1200bps open/close on port COM26
PORTS {COM3, COM4, COM26, } / {COM3, COM4, COM26, } => {}
PORTS {COM3, COM4, COM26, } / {COM3, COM4, COM26, } => {}
PORTS {COM3, COM4, COM26, } / {COM3, COM4, } => {}
PORTS {COM3, COM4, } / {COM3, COM4, COM26, } => {COM26, }
Found upload port: COM26

At the moment that you see the "Forcing reset" message and the first "PORTS" line, you can manually reset the board; that should get your manual timing correct.

It's definitely being recognized by windows, and the port's either COM6 or COM8 for me depending on which USB port it's plugged into, they never change.

The onboard status LED does blink normally though! It even blinks when the reset button is being held, not sure if that's normal or not.

So one thing is the timing on that Force Reset line is that it goes by so fast, but I can keep trying the timing throughout the day. Although here's something interesting!

When normally try to upload code to the board, it will show

PORTS {COM8, } / {} => {}
PORTS {} / {} => {}
PORTS {} / {} => {}
PORTS {} / {} => {}

So it'll recognize the port, but then it disconnects before the connection can be finalized, at least that's my guess. If I hold down the reset button until it's done compiling, it'll start by seeing nothing on any of the ports, and will then say

PORTS {} / {} => {}
PORTS {} / {} => {}
PORTS {} / {COM8, } => {COM8, }

Which I guess makes sense since it's able to connect, but then it's just the programmer that isn't working.

It's a weird problem, and I'll just keep playing with the timing of the reset button. I feel like something could have gotten messed up in the chip itself since the timing of executed code was 10x slower than when they worked. Thanks for all of your thoughts so far!