Go Down

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

baselsw


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?




I think Nick wrote something about the empty blocks in the bootloader (the FF bytes) and how they give you some trouble uploading sketches. Here is the thread link http://arduino.cc/forum/index.php/topic,104780.60.html

He apparently changed all the 0xFF bytes to 0x00 and that somehow solved the problem. But I really don't know how he changed those bytes, and when I asked him he said that he can't find any errors in the optiboot mighty bootloader.

I already tried the official optiboot bootloader from the resp. and that gave me the same results. That's obvious because maniacbugs bootloader is up to date with the official one (already checked both and  they match).

I don't have crossroads PCB nor sanguino, so I don't have anything to compare with besides my setup on the  breadboard.

pito

The 1.0.1 IDE allows to upload the sketch via the programmer. It works fine all the time, even faster than the bootloader..

baselsw


The 1.0.1 IDE allows to upload the sketch via the programmer. It works fine all the time, even faster than the bootloader..


I know that and i've already tried it (i'm using 1.0.1). But if it's working for others (with the FTDI) then I would want to know why it's not working for me. Secondly it's more debug friendly (the FTDI). So if that is possible and others got it to work I will be more than happy to be in their seat right know.

pito

#453
Aug 08, 2012, 01:16 pm Last Edit: Aug 08, 2012, 01:18 pm by pito Reason: 1
..and because of this bootloader mess (I am using 32, 328, 1284p at different frequencies than 8 and 16MHz) I am using the programmer (homemade usbasp) and I am very happy since then. The bootloader with 1284p (2-3y ago) worked fine with an old FTDI module (mind the reset capacitor at DTR).

wanderson



The 1.0.1 IDE allows to upload the sketch via the programmer. It works fine all the time, even faster than the bootloader..


I know that and i've already tried it (i'm using 1.0.1). But if it's working for others (with the FTDI) then I would want to know why it's not working for me. Secondly it's more debug friendly (the FTDI). So if that is possible and others got it to work I will be more than happy to be in their seat right know.


I would suggest that burning a sketch with the ISP, then using the FTDI to test serial output.  In other words, isolate if the problem is with the serial communication or with the bootloader functionality.
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

baselsw




The 1.0.1 IDE allows to upload the sketch via the programmer. It works fine all the time, even faster than the bootloader..


I know that and i've already tried it (i'm using 1.0.1). But if it's working for others (with the FTDI) then I would want to know why it's not working for me. Secondly it's more debug friendly (the FTDI). So if that is possible and others got it to work I will be more than happy to be in their seat right know.


I would suggest that burning a sketch with the ISP, then using the FTDI to test serial output.  In other words, isolate if the problem is with the serial communication or with the bootloader functionality.


Here you go! Working like there is no tomorrow!

baselsw

I wanted to keep everyone up to date on what I've done for 6 hours.

* Changed the bootloader (Mighty 16Mhz optiboot) baud rate to 19200
- compiled and burned successfully
- Results: The upload procedure went farther than before but ended with getsync and get disabled errors.

* Changed the fuses to allow the bootloader block to be 1024 words ; High fuse = D8
- Tried with the Mighty 16Mhz optiboot bootloader
- Results: stk500_cmd(): protocol error

* Found an old bootloader for the mega1284p and simply burned and tried.
- Results: Same error as previous

* Tried a bunch of caps of various sizes (between 6pF to 100pF, by connecting them in parallel; series; etc)
- Results: Feeling mentally ill and tried to kill my self a couple of times during the process!!!! And no didn't work. Everything except for the 22pF gave getsync error.


wanderson

One more thing you may try is to change your avrdude preferences to use a slower Baud rate.
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

florinc

Also, try a different bootloader. I used the one from calunium, and that has been working flawlessly (never got an upload error) for me for a while.


Also, try a different bootloader. I used the one from calunium, and that has been working flawlessly (never got an upload error) for me for a while.


Flawlessly?  A communication error on upload is not that dissimilar to a 644p/1284p communication error running the same sketch.

Quote
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?)


@westfw: Sanguino 1284p has been tested bootloader is not taking with USBasp.  Same with Calunium Optiboot and non-Optiboot 16MHz.  For some odd reason the 1284p has got to be just taking the bootloaders (properly) from AVRISP/DRAGON programmers.  I have no 644p to test.  I have a diff file of the avrdude verbose between a working and non-working with the only significance in the hfuse (0xDC vs DE).  Too small of a delta to really matter.  Getting End to End with only Arduino pieces is going to take some work.
http://www.spcomputing.com

CrossRoads

Getting mini 1284's up & running okay on this thread
http://arduino.cc/forum/index.php?topic=112020.new;topicseen#new

I bootloaded mine using AVR ISP MKii from the IDE with this bootlloader and this boards.txt entry.

Code: [Select]

##############################################################

bobuino.name=Bobuino
bobuino.upload.protocol=arduino
bobuino.upload.maximum_size=130048
bobuino.upload.speed=115200
bobuino.bootloader.low_fuses=0xff
bobuino.bootloader.high_fuses=0xde
bobuino.bootloader.extended_fuses=0xfd
bobuino.bootloader.path=optiboot
bobuino.bootloader.file=optiboot_atmega1284p.hex
bobuino.bootloader.unlock_bits=0x3F
bobuino.bootloader.lock_bits=0x0F
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino
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.

Quote
I bootloaded mine using AVR ISP MKii from the IDE with this bootlloader and this boards.txt entry.


We understand the MkII and all the others of that flavor work wonderfully.  Some of us are perplex as to why the Arduino hooked up ICSP will  upload bootloaders to 168, 328, 1280, 2560 just fine, but not the 1284p.
http://www.spcomputing.com

CrossRoads

Check Nick Gammon's site on this.
http://www.gammon.com.au/forum/?id=11637
Scroll about 2/3 down the page. He shows bootloading a '1284 from Uno as ISP.
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.

baselsw


Check Nick Gammon's site on this.
http://www.gammon.com.au/forum/?id=11637
Scroll about 2/3 down the page. He shows bootloading a '1284 from Uno as ISP.


I've already tried that. And tried everything everyone else suggested here. I even changed from burning the bootloader with my Mega ADK R3 to my home made UNO. The burning is always successful and the bootloader MD5 sum is the same as for Nick. So everything went well. But I always get the same error when trying to upload any sketch. I'm beginning to give up on this.

I'll give it another try tonight after work. If it dosen't work then i'll integrate a ISP programmer in the circuit so it in the end is programmable and debug-gable through FTDI.

westfw

I wonder if there is some issue with the ftdi and (perhaps) your host software.  HW flowcontrol being enabled, or something.
Which FTDI board are you using?  I doesn't seem to match any of the Arduino, Sparkfun, or Adafruit boards.

Go Up