Go Down

Topic: ATmega1284P: End to End using 1.0 IDE (Read 81223 times) previous topic - next topic

CrossRoads

I can't access those pages from here. Will look when I get home.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

wanderson

If your crystals are speced for 30pF, the 18pF would be worse than your 22pF.  In my case my crystals were spec'd for 18pF and had problems with 22pF caps, which are closer to the crystal spec than your 22pF are to your crystal's 30pF spec.

Do you have an oscilliscope?  It would be good to look at the oscillator waveform as well as the serial waveform.
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

baselsw


If your crystals are speced for 30pF, the 18pF would be worse than your 22pF.  In my case my crystals were spec'd for 18pF and had problems with 22pF caps, which are closer to the crystal spec than your 22pF are to your crystal's 30pF spec.

Do you have an oscilliscope?  It would be good to look at the oscillator waveform as well as the serial waveform.


No, I don't have an oscilliscope. I'm a chemical engineer with a burning interest for electronics, so no expensive equipment here =P! Well i've already tried a couple of 30pF capacitors and even 47pF. All with the same output :S. It's kinda weird because I have the exact same crystal with 22pF capacitors on my home made UNO's, and it's working! And I'm programming my UNO's with the same FTDI board. So no problem there. If you look at my AVRDUDE output files from the previous post you'll see that my PC is successfully talking to the mega1284p. But something weird happens along the way. The connection suddenly times out in some way and later ends with the programmer is not in sync error.  I can't explain nor understand what happened because the output is in HEX greek language =P!

Got any other ideas maybe??

florinc

Quote
I have the exact same crystal with 22pF capacitors on my home made UNO's

Do you share the crystal betweee the boards? :)
They may look identical, but they are still different.

baselsw

#439
Aug 07, 2012, 10:23 pm Last Edit: Aug 07, 2012, 10:25 pm by baselsw Reason: 1

Quote
I have the exact same crystal with 22pF capacitors on my home made UNO's

Do you share the crystal betweee the boards? :)
They may look identical, but they are still different.



Loolll! I'm not an electrician but I do know how to read datasheets and order the exact same type of crystal =P! The crystals look the same and are of the same type/manufacturer/Load capacitance spec etc.. I promise =P! And the answer is no, I don't share the same crystal between boards. Much cheaper to just buy a bunch (time de-soldering = money).

kf2qd

As always, just because you ordered the "same" parts it doesn't mean they are all exactly the same. If they came from the same lot and were not pre-tested then you might have wound up with one that is out of spec and thus doesn't resonate correctly. Unless you can replace it with a known good working part you won't know if there is a problem with that particular crystal.

Personally I would doubt the problem being with the crystal, and instead I would look at bad connections/solder joints that are changing with slight changes in temperature.

westfw

avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv: . [14] . [1e] . [97] . [05] . [10]
################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: Send: V [56] . [a0] . [0f] . [fc] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [0f] . [fd] . [00]   [20]
avrdude: Recv:
avrdude: stk500_cmd(): programmer is out of sync

This is a very weird time for the programming to fail.  It has executed a significant number of commands, indicating that communications is basically working.  The 'V' command is not actually supported (this piece appears to read eeprom, for some reason), so the result is "faked", but that's already worked once as well.
Does the failure always happen in this same place?

baselsw


avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv: . [14] . [1e] . [97] . [05] . [10]
################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: Send: V [56] . [a0] . [0f] . [fc] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [0f] . [fd] . [00]   [20]
avrdude: Recv:
avrdude: stk500_cmd(): programmer is out of sync

This is a very weird time for the programming to fail.  It has executed a significant number of commands, indicating that communications is basically working.  The 'V' command is not actually supported (this piece appears to read eeprom, for some reason), so the result is "faked", but that's already worked once as well.
Does the failure always happen in this same place?



Ya, the error always happens in the same place. I tried re-uploading the sketch like 30-40 times with the error appearing at the exact same place! That's why I don't think it's a faulty crystal. If it's a faulty crystal then the error should come randomly at any place.

Do you know what the reason is/can be for this kind of behavior?

baselsw


As always, just because you ordered the "same" parts it doesn't mean they are all exactly the same. If they came from the same lot and were not pre-tested then you might have wound up with one that is out of spec and thus doesn't resonate correctly. Unless you can replace it with a known good working part you won't know if there is a problem with that particular crystal.

Personally I would doubt the problem being with the crystal, and instead I would look at bad connections/solder joints that are changing with slight changes in temperature.


I agree, but the thing is that this is on a breadboard = no soldering and the connections are fine, successfully programmed the bootloader with the same connections/wires.

westfw

Well, if the watchdog was somehow not being reset properly, then it might reset the cpu at a fixed time into the upload procedure.  But I'm not sure how that could happen.  I wish the debugging output had timestamps.

But if this were the case, I'd think that it would not work for anyone, ever...

I have spent the better part of the day tinkering with the Optiboot and I get the same issue.  An easy way to reproduce it is to burn the bootloader with non-MkII equipment (ArduinoISP/USBasp) and then upload a BIG sketch (my test was the Mega modified Show Info).  The same burst happens and then the same thing that baselsw gets.  I manage to get a stk_500 [64] page error after the burst (via FTDI).  If I use the "Old Mighty 1284" it uploads no trouble.  Loading "Blink" on the Optiboot 1284p breadboard works fine.

http://www.spcomputing.com

baselsw

#446
Aug 08, 2012, 06:46 am Last Edit: Aug 08, 2012, 07:06 am by baselsw Reason: 1

I have spent the better part of the day tinkering with the Optiboot and I get the same issue.  An easy way to reproduce it is to burn the bootloader with non-MkII equipment (ArduinoISP/USBasp) and then upload a BIG sketch (my test was the Mega modified Show Info).  The same burst happens and then the same thing that baselsw gets.  I manage to get a stk_500 [64] page error after the burst (via FTDI).  If I use the "Old Mighty 1284" it uploads no trouble.  Loading "Blink" on the Optiboot 1284p breadboard works fine.


Well, I've already tried the original mighty bootloader and it dosen't get better. The uploading process is a little slower (lower baudrate) but that's it. The thing ends I believe with either the same programmer not in sync or simply not in sync error.

I'm burning the bootloader with my Mega R3. But I don't think that's the problem. Well, what's the difference between a real MKII programmer and Mega R3?? Maybe high voltage programming vs low voltage??

This is very strange because the same setup and same type of components with the same uploading procedure works fine for the atmega328p. But if the bootloader is working for someone else then am probably doing something wrong here.

@ Westfw: Can you please look at my output from burning the bootloader (Post #434)? If something fishy happened during the burning it should be somewhere there, right? How do you know if the watchdog got reset properly? Is it possible that the watchdog is resetting the chip during the uploading process?


Edit: If you look at the bootloader burning then I believe something strange is there. The burning process begins with burning a big block of only FF(=255). Then comes two different blocks with a bunch of different hex values.

Beginning:
Code: [Select]
avrdude: Send: d [64] . [01] . [00] F [46] . [05] . [04] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] .......

Different hex values right after the beginning:
Code: [Select]
avrdude: Send: d [64] . [01] . [00] F [46] . [11] $ [24] . [84] . [b7] . [14] . [be] . [81] . [ff] . [f5] . [d0] . [85] . [e0] . [80] . [93] . [81] . [00] . [82] . [e0] . [80] . [93] . [c0] . [00] . [88] . [e1] . [80] . [93] . [c1] . [00] . [86] . [e0] . [80] . [93] . [c2] . [00] . [80] . [e1] . [80] . [93] . [c4] . [00] . [8e] . [e0] . [ce] . [d0]   [20] . [9a] . [86] . [e0]   [20] . [e3] < [3c] . [ef] ...

baselsw,

Do you get any "stk500_page_write()" errors with FTDI sketch upload?
http://www.spcomputing.com

baselsw

#448
Aug 08, 2012, 08:18 am Last Edit: Aug 08, 2012, 08:22 am by baselsw Reason: 1

baselsw,

Do you get any "stk500_page_write()" errors with FTDI sketch upload?


Nopp, only programmer is not in sync and eventually Not in sync.

But let us say that I do get that error, is there a fix for that? You never know, maybe that "fix" would solve my problem!

Edit: BTW, I can "burn" the blink sketch through ISP without any problems and it works every time. But the FTDI is much more debug friendly, so I really want that to work!

westfw

I didn't see anything suspicious in the bootloader upload log.  Keep in mind that optiboot is only 512 bytes, so there isn't a lot of room for things to go wrong.  The fuses looked right.)  (Hmm.  The minimum bootloader size on 1284 is 1k, so half of it is blank.  I wonder if that has something to do with it, if that wasn't as blank as expected, or something.)

I'm a bit confused by all the different versions of optiboot for the 1284 that people are using.
If people would try the 1284 optiboot from its official repository (http://code.google.com/p/optiboot/downloads/detail?name=optiboot_atmega1284p-4-5.hex&can=2&q= ), I might be able to slip some extra debugging code in there to find out what is actually going on.  (and ... which pin (if any) do people have LEDs connected to?)

The failures of pageWrite (expecting 14, got 64), and the failures of the "V" command (received nothing) are significantly different behaviors, though they could have the same root cause.

Is anyone having either failure using Crossroad's PCB (The one laid out for the FTDI module), or an older Sanguino with 1284p installed? (those are what I have.)  Or is this on other hardware?


Go Up