Howdy,

Okay -- got my first Peggy2 running -- and it's gorgeous!

This is my first shot at AVR stuff and just got the arduino environment up and running. I was able to program a few simple examples into the board 9that is, I loaded them as sketches, set the board type, compiled/verified them and then uploaded via the USB/serial connector.

Then I loaded the static display. Looks great!! But now I can't load anything else. When I try to upload any other demo, I get

I'm under linux and I've tried plugging and unplugging the USB /Serial connector, cycling power to the Peggy, both in concernt, etc. It never gets going. I've also tried hitting the reset button on Peggy which clearly works to reset, but the doesn't seem to help the upload.

Any suggestions on where to start? I know this is probably an arduino thing, but wanted to check in case there was anything known here. I did google around for stuff, but no one has the resp-0x4b code -- most have a resp=0x00 which means the units can't communicate.

Thanks!

Gerry

One bit of info in case I wasn't clear -- the peggy2_GrayTest worked fine and continues to run fine in the Peggy2 -- just can't load anything else (I say this in case I made it sound like the board was dead or something)

Gerry

So that I understand this, please verify: You are using the Arduino environment with the Peggy 2 library and the USB-TTL cable. You were able to upload different programs, but now you can't, for no apparent reason. Is that right?

First thing to check: Are you doing *anything* else that might prevent your serial port from working? Other programs that access serial ports can interfere with operations, maybe without completely preventing communication. (Happens to me all the time-- think I've fried a Meggy, but it always turns out to be that I was accessing the serial port from another program without realizing it.)

You might also start with <A HREF="http://www.ladyada.net/learn/arduino/help.html">this list</A> of things to look at, but I'll see if I can reproduce the error too. I don't think that I've seen this before, and it *should not* be possible for anything loaded via the USB-TTL cable to interfere with programmability.

Finally, it could be a connection issue. If you have an intermittent connection to the USB-TTL port, or on the resistor or capacitor, or to pin 1 of the chip, or are touching the pins with your fingers or (let's hope not) something conductive, it can prevent operation.

So you can run (1) the static display and (2) peggy2_GrayTest, but nothing else?

I'm confident that nothing else is using the serial port (used OS tools to confirm nothing else has it open/locked/shared/etc).

Yes -- I was able to load two simple examples in OK, the last one being the static one. Since that was loaded, I've not been able to load any others (static was loaded only once and is still running).

I'm going to replace the AVR with one of the other Peggy AVRs and see if I can reproduce this.

If I truly can't get avrdude to work, is my only other option is use an an ISP programmer?

Thanks,

Gerry

If I truly can't get avrdude to work, is my only other option is use an an ISP programmer?

Avrdude is the part of the programming environment that communicates with the hardware programmer. It's used by both the Arduino environment and (almost certainly) the software that you would use with an ISP programmer-- it's probably quite innocent in the process. In any case, if something is wrong, it's *probably* in the board or your software setup and not in the AVR.

I've just checked to make sure with a Peggy 2 here, and I don't see any trouble programming and reprogramming (including before and after the static program) through Arduino 12, the current version of the environment.

Well, this is going to perhaps sound stupid, but again, this is my first AVR/Arduino project.

I think the problem is that with Peggy2, the lines that the USB/TTL interface use are also used by the LED panel, so when a very active app like the static one, is running, the LED toggling the line interferes with programming.

So, what I eventually found (after reading about the fact the Peggy2 uses those same lines and slowly putting 2 and 2 together in my mind) was that if I start an avrdude upload, then press the reset button, I can load something new most of the time (there is a timing element to this).

Of course, this is probably obvious to someone who has been doing this for a while, but as a newbie (and since it worked with a few other less demanding uploads), I didn't realize this.

Sorry for wasting your time on this :-)

Gerry

You haven't wasted anyone's time.

I think the problem is that with Peggy2, the lines that the USB/TTL interface use are also used by the LED panel, so when a very active app like the static one, is running, the LED toggling the line interferes with programming.

I do not actually think that this is the case. This type of programming uses a "bootloader," which is a small program that resides in a certain part of the chip's flash memory. The bootloader runs automatically, and *only* right when the chip resets (reboots). The bootloader runs for a few moments between power on and when it times out (if it doesn't detect anyone trying to program it), at which point the chip begins to execute the main program.

This all means that the chip can *only* be programmed right after it resets, and well before it even begins to execute the main program-- so even if Peggy does move around the TX/RX lines during the main program, that isn't really an issue for programming.

In the early Arduino devices, you would push the reset button by hand to initiate programming, and there was a long (10 s) delay after turn on so that you'd have a big window to push the button. In newer versions, there's a feature called "auto-reset" that we're taking advantage of. The way that this works is that it uses a capacitor (C6 in our case) along with a resistor (RA4 in our case) to allow the reset pin to be pulled low-- just as if you had pressed the button-- when the right pulse appears on the FTDI cable. It should do exactly the same thing.

Since it's not working, the likely causes are (1) there's a hardware problem (check RA4, C6, values, soldering, and the surrounding area) and (2) there's a software problem.

On Windows this can sometimes be fixed with the "Set RTS setting":
Device Manager -> Com Ports -> USB Serial Port -> Port Settings -> Advanced button -> Set RTS On Close

On Linux there's a hack too:
http://moderndevice.com/phpBB3/viewtopic.php?f=15&t=14