Flashing 1284P

Other Hardware 3rd Party Boards
41

oric_dan:
If it suddenly started working, then it was probably a loose wire. Check your connections. I presume you're using the soldered prototype now. I meant to say this before about whiteboards - bad connections are probably the source of about 90% of people's problems. I never use them. Also, like westfw indicated, I "always" wire up the back-side gnds, Vcc, and Vref pins.

Migrating to the 1284P | The Robot Diaries <--- that link is a riot. No references. His comments are straight out of the excruciatingly long forum thread in 2013, 27 pages or so, where we debugged the RX0 problem using eternal frustration as the motivation.

Also, Serial1 works 100% on the 1284, I use it all the time. So, check your connections and setups.

Also, all the SoftSerial libraries are a POS from my experience, although others swear by them, and you find 100s of examples of their use. They may work somewhat ok for RX only on 1 channel, but are useless for real 2-way comms in my experience. If you must use SoftSerial, try PaulS' AltSoftSerial from the pjrc.com site. I've not used it, but the description sounds like it's competently coded. Try it, and report back, I'd be interested to hear of someone's experience with it, :-).

Also, re your comment on the other thread, I tried the ESP8266 back in December, and gave up on it immediately. Very unreliable. There are MANY threads in the Networking section of people not being able to get it to work properly. I've not checked recently, so maybe someone has had better success now.

Also, despite others' hesitations on the matter, I use 16-Mhz with Vcc=3.3V every single day. Perfect reliability, although I don't go to 80 degC, etc.

I'm not really sure where the problem was to be honest.

I went round in circles and did everything 10 times on my breadboard and prototype board.

All I'm thinking is when I moved to my prototype board I didn't use nick gammons sketch to upload the bootloader and used maniacbug library to do so.

However when I used it just before on the prototype board then it suddenly worked; I could flash the chip with my own sketches. Which could be related to his sketches changing the necessary fuses before uploading the same bootloader.

However I'm sure the fuses were changed.

I read that whole thread from 2013, are you basically saying the hardware problem doesn't exist or there is some type of problem with UART 0's RX?

As I need to heavily rely on this for my product as firmware upgrades will be done through a USB to Serial FTDI with UART 0.

I've just tried Serial 1 and Boom. it works, which is a huge relief and weird. I don't need an extra UART for now so Serial 1 will do but I will save them links for later use.

When you say "all the SoftSerial libraries are a POS from my experience", what do you mean by POS?

I came across a thread funnily enough from 2013 that discussed problems with the 1284 and software serial,

http://forum.arduino.cc/index.php?topic=157297.0

It talked about the need for modifying the software serial library to get it to work, this was 2 years ago have you heard anything since with your experience of the chip?

42

"Many" people had the RX0 problem. I believe it does exist and is related to cross talk between Xtal and RX0 pins, as noted on the long thread. Since going to full-swing oscillator, I've not heard of anyone having it.

I suggest trying AltSoftSerial. Read the comments here:

https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

43

BTW, now that you've burned the 16-MHz optiboot into the chip, you can 'compile' for any of the variants in boards.txt that list the same boot loader, eg Bobuino.

44

oric_dan:
"Many" people had the RX0 problem. I believe it does exist and is related to cross talk between Xtal and RX0 pins, as noted on the long thread. Since going to full-swing oscillator, I've not heard of anyone having it.

I suggest trying AltSoftSerial. Read the comments here:

AltSoftSerial Library, for an extra serial port

I can think I'll have to agree with you there.

Looking at the library under hardware requirements it has specific boards listing the Uno and specific TX and RX pins. The library doesn't look compatible with the 1284?

Can you clear a burning question I've been having,

I understand you have a bootloader which is a piece of software that is burned onto the a MCU and allows you to reprogram it without the need of a programmer.

maniacbug library provides the bootloader for the 1284.

However what's the part that converts the arduino code into usable code for the MCU to understand. I understand that complier converts my code into machine code for my MCU but every MCU needs the code to be complied differently because of different pins, specs etc..

Within my IDE I choose, "Arduino Uno" or "Mighty 1284p" which sets up my complier to compile for the right chip. Is there an abstract explanation to this with terminology? What does maniacbug library provide apart from the bootloader?

45

CrossRoads:
What is bringing power to the far power rails?

Good point. Nothing it seems. My bad.

46

jacktrow1:
However what's the part that converts the arduino code into usable code for the MCU to understand. I understand that complier converts my code into machine code for my MCU but every MCU needs the code to be complied differently because of different pins, specs etc..

Within my IDE I choose, "Arduino Uno" or "Mighty 1284p" which sets up my complier to compile for the right chip. Is there an abstract explanation to this with terminology? What does maniacbug library provide apart from the bootloader?

Part of the compiler output is a .hex file which is what the programmers read and burn onto the chip.

The settings in the boards.txt file set various compiler defines which tell the avr-gcc which is the target architecture, which will let it know (or the defines might) things like maximum memory, the exact chip type, etc. For example the Atmega328 chip will have different instructions than the Atmega1284 (at least in some cases). As an example, addressing past the 64k boundary will involve extra steps because it needs to either use longer pointers, or take other steps to tell the CPU which part of RAM to look at.

I'm not at my Arduino PC right now so I can't give you exact file names, but I think the Maniacbug library (and others) have alternate files like pins_arduino.h which map the pins (like D1, D2 etc.) to the ports (eg. PORTB, PORTC etc.).

47

Nick, can you take a look here?
http://forum.arduino.cc/index.php?topic=304656.0
Having trouble getting the programmer to work.

48

CrossRoads:
What is bringing power to the far power rails?

I must have realized the error of my ways. My current breadboard has wires connecting Gnd and Vcc from one side of the board to the other. I just republished an earlier photograph before.

49

Within my IDE I choose, "Arduino Uno" or "Mighty 1284p" which sets up my complier to compile for the right chip. Is there an abstract explanation to this with terminology? What does maniacbug library provide apart from the bootloader?

There are a couple of things that happen based on "board" type in arduino:

  1. The xxx.build.mcu and f_cpu are passed to the compile commands for each source module. This in turn controls which "chip definition" file is included by the "#include <avr/io.h>" statement that us buried some some arduino core file.
  2. based on the LOCATION of the boards.txt file that contained that particular board definition, the arduino IDE derives candidates for the "bootloader", "core" and "variant" directories that are used in the build (these can be overridden by the xxx.build.core and xxx.build.variant definitions.)
  3. It's relatively common for new boards to have a specific variants/xxx/pins_arduino.h that defines how the arduino "pin number" are mapped to the avr port/bit combinations (particularly a problem with the 1284, since different boards have taken different philosophies WRT this mapping. In theory, the mapping is completely arbitrary. However, some boards are more careful about putting PWM-capable pins in the same place, or SPI pins in the same place, or ... etc.)
  4. information from (1) and (2) gets used in "conditional compilation" in the core files, either directly based on processor type ("#if defined AVR_ATmega1284P" or by the peripheral information from io.h (ie: "if there's a 2nd UART, include code for a 2nd UART": "#ifdef USART2_UDRE_vect")
50

Jack, I looked at the AltSoftSerial library. Here's your opportunity to learn how things work. There are a couple of files with callouts for ATmega644P, and then 3 I/O pins declared to use for the interface. I should imagine all you need do is change 644 to 1284, and change the pin#s to the ones with the exact same functions as mapped to for the 1284 variant you are using. And it should work. An hour or two to figure out what you're up to, and 5-minutes work to change it.

51

oric_dan:
Jack, I looked at the AltSoftSerial library. Here's your opportunity to learn how things work. There are a couple of files with callouts for ATmega644P, and then 3 I/O pins declared to use for the interface. I should imagine all you need do is change 644 to 1284, and change the pin#s to the ones with the exact same functions as mapped to for the 1284 variant you are using. And it should work. An hour or two to figure out what you're up to, and 5-minutes work to change it.

I will be need software serial down the road so this is perfect thank you!

However currently I'm in a bit of a headache again,

I've got the chip all up and running with my esp8266 module on UART1 and debugging using my FTDI on UART0.

I've also got a 2.8" TFT LCD attached made by Adafruit,

Steps I followed to set up,

I've used it countless times with my Atmega328 however I can't seem to get it to work with my 1284P.

It has a controller board which I connect to via SPI.

It uses a brilliant library which I define the SPI pins like so,

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_MOSI, TFT_CLK, TFT_RST, TFT_MISO);

I've connected :

CS pin to D0,
DC pin to D1,
RST pin to D3

Then hardware SPI pins on the 1284P are :

MOSI to D5
MISO to D6
SCK to D7

So my library definition is as follows :

Adafruit_ILI9341 tft = Adafruit_ILI9341(0, 1, 5, 7, 3, 6);

I've checked each of these connections using a multimeter so there are defiantly correct.

Does hardware SPI work on the 1284P and there should be no reason why Adafruit's library shouldn't run?

52

westfw:
There are a couple of things that happen based on "board" type in arduino:

  1. The xxx.build.mcu and f_cpu are passed to the compile commands for each source module. This in turn controls which "chip definition" file is included by the "#include <avr/io.h>" statement that us buried some some arduino core file.
  2. based on the LOCATION of the boards.txt file that contained that particular board definition, the arduino IDE derives candidates for the "bootloader", "core" and "variant" directories that are used in the build (these can be overridden by the xxx.build.core and xxx.build.variant definitions.)
  3. It's relatively common for new boards to have a specific variants/xxx/pins_arduino.h that defines how the arduino "pin number" are mapped to the avr port/bit combinations (particularly a problem with the 1284, since different boards have taken different philosophies WRT this mapping. In theory, the mapping is completely arbitrary. However, some boards are more careful about putting PWM-capable pins in the same place, or SPI pins in the same place, or ... etc.)
  4. information from (1) and (2) gets used in "conditional compilation" in the core files, either directly based on processor type ("#if defined AVR_ATmega1284P" or by the peripheral information from io.h (ie: "if there's a 2nd UART, include code for a 2nd UART": "#ifdef USART2_UDRE_vect")

Thank you for your detailed response its really appreciated!

I've read it through multiple times and my understanding is growing, I'll refer back to this and other posts when I start to dig deeper!

53

That's brilliant nick, that's boosted my understanding further.

So for example within boards.txt you have a Atmega328 definition,

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

uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
uno.bootloader.low_fuses=0xff
uno.bootloader.high_fuses=0xde
uno.bootloader.extended_fuses=0x05
uno.bootloader.path=optiboot
uno.bootloader.file=optiboot_atmega328.hex
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.core=arduino
uno.build.variant=standard

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

And this holds a lot of the information that is passed to the complier to create the .hex file which is untimely uploaded onto the chip.

I understand fuses to the extend of there are essentially hardware 'settings' that are saved for things like oscillators configuration.

However could you elaborate on low and high fuses and lock bits.

54 
[quote]Does hardware SPI work on the 1284P...?

Hardware SPI on the 1284P works great! I've cranked out data using 8 MHz clock (SPI divisor set to 2, the max speed), and even turned off interrupts to make data blast out even quicker, nearly a byte/uS.

55

addressing past the 64k boundary will involve extra steps because it needs to either use longer pointers,

Only for PGMSPACE. Most of the instructions that reference flash (jump, call, etc) use word addresses, and don't change until the 128k boundry. (This is why optiboot can work on the 1284 and 1280, but not the 2560.)

56

Fuses? This site helps you see visually what the fuses do:

http://www.engbedded.com/fusecalc

As for lock bits leave them alone. The general idea is to make it hard or impossible for people to read your code back and copy it. Sort of a copy-protection thing.

57

Thank you that's a great site!

Looking as bownout detection at 2.7V, will the chip just reset or is there a way to inform the user that the device is running low?

And about my other question, there should be no reason why the Audifruit library for my TFT LCD shouldn't run on the 1284P if it runs on the mega and uno? Everything seems standard and the only things that are specifc to the library are SPI pin connections which I've defined.

Could there be anything I'm missing?

58

I think the brownout causes a reset. You can detect after the reset that the brownout occurred.

There are ways of measuring the internal Vcc so as to be aware that it is getting low.

59

Adafruit_ILI9341 tft = Adafruit_ILI9341(0, 1, 5, 7, 3, 6);

Jack, did you get the TFT working yet? There are several problems I see.

  1. you're obviously using the 1284 standard variant, whereas Bob and I prefer the Bobuino
    variant, so it takes us a lot of cross-referencing to fix your problems [poor us].

  2. if that library is like other of ada's libraries, it's possibly an orphan, as she's constantly
    discontinuing old h.w., and upgrading to new h.w., and barely keeping the libraries up
    to date, or else they no longer work with the old h.w. It's kind of a wasteland over in
    adaland. However, sounds like this may not be your problem.

  3. her libraries may have "specific" callouts for the different cpus, as I've mentioned before
    with SoftSerial, and may not support the 1284. You need to check this.

  4. if the constructor you're using is like the one in her ST7735 LCD library, then it calls the
    "software" SPI code, and not the h.w. SPI peripheral. You might want the other constructor.

  5. in any case, you need to use the SPI SS pin for CS and not some other pin, because
    to enable the h.w. SPI peripheral, its SS pin has to be configured as OUTPUT. This is true
    for all Rduino chips, as I understand it.

60

Aloha --
I stumbled upon this thread in a google search. I too received a couple 1284P's from Mouser a couple days ago and followed maniacbug's and Nick Gammon's tutorials. I too received the same errors the OP got. I could upload the Blink sketch no problem, but when trying something more ambitious, like loading up a 14kb IMU AHRS sketch I would get those same out of sync errors.

I was using a generic FTDI breakout from an auction site. When I switched to a branded FTDI (Modern Device USB BUB II), no more sorrow. It seemed the generic FTDI would just quit half-way through the larger upload and the IDE would spit out those orange error messages.

My set up is straight out of the tutorials, no fiddling. I started the project on a WinXP-SP3 Thinkpad, got all working, and moved over to a Win7 Thinkpad, and still all good. I could not determine in this thread what the end solution was however. In my case it was the FTDI, as swapping between the two would give repeatable results. Strange, that generic FTDI has worked fine with 328P's.

So, what was the solution to the OP's predicament?

Me ke aloha.