Go Down

Topic: Using the 1284p/664p (IDE, bread board and boot loaders) (Read 26070 times) previous topic - next topic

cowasaki

Now I'm even more confused.....

I discovered that:

It will program straight after being flashed.
It will program 95% of the time IF you hit reset just as the baud rate appears in the verbose listing.
It does the same under Windows OR MacOS

I did think that it was because the program running was churning out massive amounts of serial data down the FTDI lead but tried uploading simple programs and these are no better.

It seems to be pointing at a fault connection to the reset line but I've checked this and built it again on breadboard?
I've even tested it with two different FTDI leads from two different companies.

Quote

It will program 95% of the time IF you hit reset just as the baud rate appears in the verbose listing.


This tells us it's entirely a reset problem.  The remaining 5% is just human inability to press it at the exact right time.

Do you have a line running from DTR to RESET through a cap?  Mine is a 0.1uF.

cowasaki

Yes, as I've explained I do have and I have checked the circuit too.  I have checked from pin 9 to the cap and from the cap to the FTDI connector with all in order plus the capacitor has also been checked!

Also I have built the circuit on breadboard as well !  It is working the same on that.

This is strange.....


cowasaki

In order to make sure it worked I just stuck to the fuses in the downloaded folder i.e.:

mighty.bootloader.low_fuses=0xff
mighty.bootloader.high_fuses=0xdc
mighty.bootloader.extended_fuses=0xfd
mighty.bootloader.unlock_bits=0x3F
mighty.bootloader.lock_bits=0x0F

#65
Jan 04, 2012, 11:25 pm Last Edit: Jan 04, 2012, 11:27 pm by stevemarple Reason: 1
Is that what your fuses are actually set to? I had a problem where I could upload using the Dragon but not with the bootloader. Then I noticed the blink sketch was running very slowly - soon realised it was using the internal oscillator with รท8 enabled, not the external crystal!

cowasaki


jaegs

Quote
I've just setup Arudino 1.0 and changed my project to work and whilst setting everything up I decided to get the 1284p working again.  I plugged in my board which I designed as per the beginning of this thread and which worked under 0.22  the program is still on the board and it started flashing away as it should.

I downloaded the zip file from your site as I wanted to get it going with v 1.0 and re-started Arduino.  The board appears under the list and I loaded my original 1284p test program (my board has 8 leds and the program flashes all 8 in various sequences).

When I click upload though it compiles correctly but then I get the error:

avrdude: stk500_getsync(): not in sync: resp=0x00


I have the same setup and same problem.  Additionally, I have an LED in pin 1. During upload with Sparkfun's FTDI basic, the LED blinks and then goes solid. If I ground the RESET pin, the LED flashes and then turns off.


avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync(): not in sync: resp=0x00


Hmm, now I am getting this problem too!  Very strange.  I recompiled with a baud rate of 38400, and it fails less often but still fails.  Also, I recompiled with the monitor on, so '!!!' throws it into monitoring.  I've noticed that once it starts failing, I can never upload again, UNTIL I launch with the monitor and type a few things.  Then it goes back to working fine for a few more times.  Odd odd odd.  Need to look for another bootloader implementation.



avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync(): not in sync: resp=0x00


Hmm, now I am getting this problem too! 
...


I was getting this with Calunium last night; sometimes it took several tries to work. I have a feeling that smaller sketches have a better probability that the upload will succeed. It's almost as if the baud rate doesn't quite match. When I was first struggling with bootloaders I even checked out the timings from my the FTDI adapator and the '1284P using an oscilloscope but couldn't see any indication of a timing problem.


Need to look for another bootloader implementation.


I think we're both using Ryan Sutton's bootloader, with maybe some minor mods?



I think we're both using Ryan Sutton's bootloader, with maybe some minor mods?


Yup.  Well, I was when I wrote that :D  Now I moved over to Optiboot.  115200 baud and not a single error all night.  So far so good!  I'll post the patch as an issue on the optiboot site after a bit more testing.

skyjumper

Hm, I installed your boot loader on my 1284P board, tested it several times from Arduino 1.0 and it worked nicely. Then I used AVRDUDE manually from the command line and it still went well, writing and then verifying with no issues. I had been using another boot loader until then and boy, did that become an unmitigated disaster :-(

Does anyone know of a boot loader that can program the uC from a hex file stored on an SD card? I ran across one but it only worked if the SD card was FAT16.



Does anyone know of a boot loader that can program the uC from a hex file stored on an SD card? I ran across one but it only worked if the SD card was FAT16.


You know, I have been thinking about this too.  What's the use case you have in mind for this?  Just curious.

skyjumper



Does anyone know of a boot loader that can program the uC from a hex file stored on an SD card? I ran across one but it only worked if the SD card was FAT16.


You know, I have been thinking about this too.  What's the use case you have in mind for this?  Just curious.


I am working on something that will be installed in a location with no computers, and where bringing one can sometimes be difficult. It's an enhanced data logger, so to speak. It collects data, logs it to an SD card, does some processing and returns processed data to another system. Users are not very technical. If they need to upgrade the application firmware, the easiest thing for them to do is to put the new hex file on to the SD card, insert the card and power up the unit. The device's boot loader could then search the SD card for a HEX file, and if it finds one, update the device.

I did run across an older boot loader for AVR that did that. The problem is that it was for SD cards with a FAT16 (I think) file system. These days, that's not something you see often at all.


I am working on something that will be installed in a location with no computers, and where bringing one can sometimes be difficult. It's an enhanced data logger, so to speak. It collects data, logs it to an SD card, does some processing and returns processed data to another system. Users are not very technical. If they need to upgrade the application firmware, the easiest thing for them to do is to put the new hex file on to the SD card, insert the card and power up the unit. The device's boot loader could then search the SD card for a HEX file, and if it finds one, update the device.


I have an application that is not too dissimilar. Update by SD card would be fantastic, especially since I have the opportunity to download upgrades via wifi. At the moment I am hoping to configure a V-USB bootloader for Calunium. Then upgrades would be possible with just a plain USB connection without needing FTDI on-board or an FTDI adaptor. Is that a possibility for you?

Go Up