Go Down

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

florinc

Burn sketches or upload sketches?
Burning sketches should be similar to burning the bootloader, just use a different hex file.

CrossRoads

@spirilis,
The Rx/Tx LEDs are not connected to the FTDI Basic or equivalent offboard module. Only to a couple of the Microelectronika module GPIO pins, same as the LEDs on an FTDI Basic module.
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

theloon

Has anyone succeeded at getting bootloader loaded on 1284p and able to load sketches using Arduino IDE only and have been able to reproduce their actions? I haven't seen proof of life yet.  :D

westfw

I have burned bootloader from the IDE,  and then successfully uploaded sketches, using one of crossroad's Bobuino boards, Arduino Uno as ISP (for burn),  and genuine FTDI cable for upload.

1) Uno connected to USB, running (patched for 1.0 bug) ArduinoISP sketch.  10uF cap insterted between gnd and RESET after the Arduino sketch is loaded.
2) Connect the Uno to the 1284 board ISP connector, ala the many tutorials.
3) Connect Bobuino to another USB port using FTDI 5V cable.
4) Select board "bobuino", select Serial port of the UNO.  Use "Burn Bootloader" command from tools menu.  Watch the lights flash for ~80s while the bootloader is burnt (quick) and verified (reads all 128k.  Slow.)  The verbose output that should be happened appears to get buffered, so it appears after all the actual work is done.
5) Select Serial Port of the FTDI cable (board still set to Bobuino), select Blink sketch, and "upload sketch."  Light starts blinking.

Does that help?  I thought we were working on finding HW bugs in the particular board that people are having problems with?

florinc

Quote
I have burned bootloader from the IDE,  and then successfully uploaded sketches

Similarly, I used adafruit's USBtinyISP to burn the calunium bootloader using the IDE, then uploaded sketches from the IDE (with the FTDI cable), as described here (this is actually a repeat of answer 293):
http://timewitharduino.blogspot.ca/2012/03/wise-clock-4-with-atmega1284.html

maniacbug


I think I recommend against using the Arduino IDE to burn the bootloader for anything that is remotely "experimental" in nature.  It hides too much of the feedback from the programming operation.  If you've built your own 1284 clone, you should be able to use avrdude from a command line directly, and that will probably work better.


I recommend using the optiboot makefile if you're bringing up your own board.  "make atmega1284_isp" from the command line does it all, AND doesn't hide anything.  It's in optiboot and in the mighty-1284p platform distro.  I've done 5 in the last week, zero problems.  As westfw says above, I think there are hardware bugs to be sorted out.

CrossRoads

I don't like waiting while all 128k got written, so I've been using the Atmel AVR ISP MKii to burn the bootloader, and then download sketches via FTDI Basic.
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

sierrasmith71

Quick question.. I have read this entire thread  and had a quick read of the Atmel data sheet on the ATmega1284 and I am embarrassed to reveal that I haven't a clue as to the difference between the 1284 and the 1284P.
The 1284P seems to cost a bit more...


Which one to use and why?
:smiley-roll:
David Garrison

Gaithersburg, MD

spirilis


Quick question.. I have read this entire thread  and had a quick read of the Atmel data sheet on the ATmega1284 and I am embarrassed to reveal that I haven't a clue as to the difference between the 1284 and the 1284P.
The 1284P seems to cost a bit more...


Which one to use and why?
:smiley-roll:
David Garrison

Gaithersburg, MD


The "P" versions of Atmel's AVR processors denote the PicoPower edition, which I don't think adds anything functional to the code/instruction set (not sure about that though) but does denote that the processor has some internal changes that make it use less power.
http://www.atmel.com/technologies/lowpower/picopower.aspx


The only thing to keep in mind is the non-P and P versions usually have different device signatures, and I'm not sure if the copy of AVRDUDE that comes with the arduino IDE has an entry in its avrdude.conf for the non-P version (with the conventional ATMEGA328, it does not) so it can make it a little more complicated to burn bootloaders or burn sketches directly with the ISP (you typically have to give the -F option to avrdude to force it to burn anyway, since otherwise it'll error with a signature mismatch).

Once you have a bootloader burned on there though, the two should basically look & work the same and you can upload sketches from within the Arduino IDE over the USB serial (FTDI cable or mikroElectronics module)

florinc

Quote
you typically have to give the -F option to avrdude to force it to burn anyway, since otherwise it'll error with a signature mismatch

Or modify the signature in avrdude.conf.

westfw

Quote
I haven't a clue as to the difference between the 1284 and the 1284P.

I'm spreading a rumor that the non-P versions are chips that failed power consumption testing late in manufacturing.  :-)
Usually when there are two versions of a chip like this, the manufacturer is pretty careful to distinguish the differences.  And in this case the non-P versions showed up AFTER the picopower versions had been released (328 vs 328P too.)
Even if this theory were to be true, it wouldn't necessarily be a bad thing...

CrossRoads

Found a difference between 1284 & 1284P!

Section 12.2 Interrupt Vectors in ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P
4 extra interrupts:
Vector: 32, Program Address: 003E, Source: TIMER3_CAPT, Interrupt Definition: Timer/Counter3 Capture Event
33, 0040, TIMER3_COMPA, Timer/Counter3 Compare Match A
34, 0042, TIMER3_COMPB, Timer/Counter3 Compare Match B
35, 0044, TIMER3_OVF, Timer/Counter3 Overflow

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

SirNickity


I have burned bootloader from the IDE,  and then successfully uploaded sketches, using one of crossroad's Bobuino boards, Arduino Uno as ISP (for burn),  and genuine FTDI cable for upload.


I am having zero luck with this.  I just got a batch of 1284Ps in from Digikey today.  Built on a breadboard, with a resonator (3-pin type) and FTDI cable for serial TX/RX.  0.1uF between DTR and reset, reset pulled-up by 22K resistor.  Used an Uno to upload the Optiboot from Maniacbug's distro package, and version 4.5 from the repo.

I get this when uploading a sketch:

Code: [Select]
         Using Port                    : \\.\COM6
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00


Swapping TX/RX makes no difference, but I'm pretty sure I got that part right to begin with.  (I use this setup A LOT for 8As and 328/328Ps.)

Uploading a sketch via programmer works fine, so I know the ATmega life support system is doing OK.  Using a modified Blink to blink pin D14, which is currently attached to the backlight of an LCD, I get on, 1s, off, 1s.. as expected.

I admit, I've not paid much attention up til now, as I just found a project that needed the I/O and RAM to justify a 1284P, so maybe I missed something obvious, but my catch-up searches haven't revealed anything useful.

I noticed that when the Blink sketch was uploaded (via ISP), there was no noticeable delay between reset and blink.  I'm used to there being a little window where the serial upload might interject before running the payload code.  Is that normal for upload via ISP?  Does that overwrite the bootloader entirely?  Or is Optiboot just not waiting?

CrossRoads

Sketch upload via ICSP means no bootloader, sketch starts immediately. No bootloader in place after that.

Which would make serial upload dead in the water.

After you get a bootloader re-installed, you might try checking the fuses. Maybe something funny is set there.

I have a similar test setup:
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

CrossRoads

#374
Apr 22, 2012, 07:44 am Last Edit: Apr 22, 2012, 07:49 am by CrossRoads Reason: 1
What I've been doing is programming fuses, programming lockbits, then programming memory.

Interface settings: 125 KHz for first time bootloading (Atmel AVR ISP MKii allows you to select the programming speed)

Memories:
C:\Arduino-1.0\hardware\mighty-1284p\bootloaders\optiboot\optiboot_atmega1284p.hex
Erase before programming- checked
Verify after programmimg - checked

Fuses:
BODLEVEL     2.7V (or as you select)
SPIEN - check
BOOTSZ - 512W_FE00
BOOTRST - check
SUT_CKSEL - EXTX0SC_8MHZ_xx_16KCK_65MS

Fuse Register
Extended -  0xFD
High - 0xDE
Low - 0xFF

Lock Bits: all show No Lock,  Lock Bit Register to show 0xFF
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Go Up