atmega1284 programming from a 328 chip

malc-c,

Can you connect a LED and resistor to chip pin 19? It want is used for Arduino pin 13. It will blink a couple of times when the chip is powered to show that the bootloader is working. Also, you will see the LED go out when reset is pressed.

Having investigated this a bit, it seems that the problem is because the Optiboot loader resets the ATMega328 when the serial port is opened. When avrdude is started up to program the slave chip it firsts opens the serial port then tries immediately to write to it. The initial comms fail because the chip has reset and, whilst in the bootloader, isn’t actually responding to the STK500 protocol.

This doesn't make much sense, because practically every 328 chip anymore uses optiboot, and they don't
fail. Unless there is some issue between uploading using the Arduino IDE via the comport, versus using a
separate programmer.

Also, as mentioned in the other recent 1284 threads, I and others have been using optiboot on the 1284
and uploading using the Arduino IDE, and it works [although a lot of people are having a 1284P problem,
still unresolved]. In my case, it always works for 328, 1284, 1284P, optiboot, 84 KByte uploads, and
the Arduino IDE in all versions.

Thanks for the replies.

I too have no idea what is happening. When the 328P is breadboarded, with DTR connected to the reset via a 0.1uF capacitor in series and a 10K pull up resistor I can select the Uno as the board in the IDE and it uploads many of the example sketches. With the 1284P chip breadboarded in the same way it fails with the errors shown.

I made the following observation:
When a successful upload on the 328P is achieved, the TX and RX leds on the FTI board initially flash a few times, pause and then flash for a longer period. It's as if the software is initially checking for the chip, the chip identifies itself and agrees to accept the code, which is then transmitted. When breadboarding the 1284P I get the initial flashes on the TX / RX leds on the FTI, but then the IDE pauses before the time out results in the errors.

I'm no expert, but it seems to me as if the bootloader is communicating correctly. I've tried different baud rates, but with the normal standard port settings.. I assume the optiboot loader uses the standard serial protocols ?

During the last days I did a lot of tests trying to solve the problem mentioned here.
If you're using the Mighty-1284p files by maniacbug, select the board "Mighty 1284p 16 MHz w/Optiboot" then put a 220K resistor in series on the line beetween the FT232 TX and the 1284p RX0 pins.

If you're using the "Original Mighty 1284p" board, then you could try with a 120K R. Or, maybe, without components.

Leo, thanks for the reply... I don't have any 220K, but tried with 100K and still no joy. I've looked through that thread and noted some comments of the baud rate, so checked the boards.txt file and noted that it stated 115200, so I tried this and again got the same sync error. I know the FTI board is working fine as I can program the 328P with no issue (no serial resistors required, and even with the port set to this fast speed).

I'm finding all this very frustrating. Programming PICs using PicBASIC now seem a lot easier compared to using larger processors other than the original arduino based 328P. I used to wonder why so many projects on the web had "shields" stacked one on top of another and then the lot placed into a box rather than the traditional breadboard and then dedicated PCB (be that stripboard or printed) approach. Having spend all this time fuffing about with the 1284P I can now see why !

One last question... having got the 328P running on the breadboard, is it possible to use that to program the 1284p via ISC using MOSI / MISO / SCK pins or do I need a dedicated programmer for that ?

Cheers

Malcolm

After reading back through this thread, it appears you never burned the bootloader into the 1284P
chip yourself, but have been assuming the chip you bought has a proper bootloader burned into it.
However, given the nature of ebay, that may be a bad assumption - given comments by others
who've bought things on ebay.

So, maybe you should just try starting over and burning the bootloader yourself, using a regular
Arduino in ArduinoISP mode.

Alternatively, scrub this mission, and just buy a 1284 board from Crossroads.

oric_dan:
After reading back through this thread, it appears you never burned the bootloader into the 1284P
chip yourself, but have been assuming the chip you bought has a proper bootloader burned into it.
However, given the nature of ebay, that may be a bad assumption - given comments by others
who've bought things on ebay.

So, maybe you should just try starting over and burning the bootloader yourself, using a regular
Arduino in ArduinoISP mode.

Alternatively, scrub this mission, and just buy a 1284 board from Crossroads.

Thanks for the comments - but the 1284p was purchased from Crossroads, with a request to have the bootloader installed. I have also purchased one of his unpopulated PCB's but not had a chance to build it due to a few component shortages in my hobby box. This was why I've breadboarded the 1284P.

The 328P purchased from e-bay works fine :wink:

Well, given all the problems here, you might just build up the minimal cktry on the Crossroads
board and try that. All you need for a minimal working ckt are the parts shown in reply #15,
unless the board use a USB chip.

He did, and a 1284P chip.
malc-c, are you having all this trouble with that chip?

You should have these settings in your boards.txt

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

and be selecting Bobuino as the board type.

This is the bootloader I installed.
This is the pins_arduino.h that goes with the board.

There was discussion in another thread that this line needs to change to make the analog pins line up correctly

// #define analogPinToChannel(p)	    ( (p) < NUM_ANALOG_INPUTS ? NUM_ANALOG_INPUTS - (p) : -1 )
#define analogPinToChannel(p)       ( (p) < NUM_ANALOG_INPUTS ? (NUM_ANALOG_INPUTS-1) - (p) : -1 ) // test to see if A0-A7 are off by 1

optiboot_atmega1284p.hex (1.47 KB)

pins_arduino.h (6.21 KB)

I'm surprised now that he had so much trouble. The Bobuino bootloader works fine, I've
burned it into several chips now. The process is straightforward, unless Bobuino forgot
to burn it [!!]. OP's setup was minimal, so hard to mess up. There's always something going
on they don't tell us, :-).

Hi Robert, yes it is the supplied chip

I extracted the Arduino IDE to a folder on my desktop. In the path C:\Users\admin\Desktop\arduino-1.0.3-windows\arduino-1.0.3\hardware\maniacbug-mighty-1284p-68ed99c I have a boards.txt file and within it there is the following section

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

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

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

I have tried selecting the bobuino from the dropdown list of boards in the IDE and still get the same error.

The chip is breadborded on a solderless breadbord, with just supply pins connected, 16mhz xtal and RX / TX lines from the working FDI board and a 10K resistor between RESET and +ve - The power is supplied from the +5v USB feed from the FDI board (in the same way the 328P is powered). I have the DTR line connected to the RESET pin via a series 0.1uf capacitor. I've also tried taking the VREF pin to +5v too.

I've tried using the trick with a series resistor inline with the TX/RX lines. Baud set to 115200, 8bit, no parity, and 1 stop bit (although all other baud rates have been tried)

@malc-c:
100K is too less. Try with 2 100K in serie (=200K).

I have tried selecting the bobuino from the dropdown list of boards in the IDE and still get the same error.

The chip is breadborded on a solderless breadbord, with just supply pins connected, 16mhz xtal and RX / TX lines from the working FDI board and a 10K resistor between RESET and +ve - The power is supplied from the +5v USB feed from the FDI board (in the same way the 328P is powered). I have the DTR line connected to the RESET pin via a series 0.1uf capacitor. I've also tried taking the VREF pin to +5v too.

I've tried using the trick with a series resistor inline with the TX/RX lines. Baud set to 115200, 8bit, no parity, and 1 stop bit (although all other baud rates have been tried)

Exactly the same optibootloader is burned into all the chips from the maniacbug directory,
so selecting any of the 1284 boards from the drop down menu will work for uploading
sketches - only the pin assignments will be different. Eg, D13 [led] is chip pin 8 for Bobuino,
but chip pin 19 for other board selections.

I assume you included the 22pF caps in addition to the xtal? Have to have those too, unless
you're using a ceramic resonator.

Have you actually measured 5V on the Vcc and Reset pins?

Also, you might try the low-pass filter in the RX0 line, people are using 10K series-R and
100pF to gnd at the RX0 pin. It's possible the chip Crossroads sent is from a batch with the
RX0 noise sensitivity.

I would also try building up the Crossroads board in minimal fashion to test.

I'm having no problems with my own 1284 test boards, so it should work for you too.

Woot, my 1284P chip from China just arrived in the mail today, so later today I will see if I have any problems upgrading my Bobuino board from a 644P to a 1284P. No time to get started in it till a little later.

Lefty

I extracted the Arduino IDE to a folder on my desktop. In the path C:\Users\admin\Desktop\arduino-1.0.3-windows\arduino-1.0.3\hardware\maniacbug-mighty-1284p-68ed99c I have a boards.txt file and within it there is the following section

BTW, I don't know if this matters, but I believe maniacbug said to locate the 1284 bootloader
files in the Arduino "sketch" directory, not the Arduino IDE directory, which is what the above
seems to indicate [maybe].

Quote
I have tried selecting the bobuino from the dropdown list of boards in the IDE and still get the same error.

The chip is breadborded on a solderless breadbord, with just supply pins connected, 16mhz xtal and RX / TX lines from the working FDI board and a 10K resistor between RESET and +ve - The power is supplied from the +5v USB feed from the FDI board (in the same way the 328P is powered). I have the DTR line connected to the RESET pin via a series 0.1uf capacitor. I've also tried taking the VREF pin to +5v too.

I've tried using the trick with a series resistor inline with the TX/RX lines. Baud set to 115200, 8bit, no parity, and 1 stop bit (although all other baud rates have been tried)

There has been a great deal of discussion of the connections and the code.. But, No mention of any bypassing.. The 100 nF caps on Vcc and AVcc are NOT optional.

Bob
(Edit for clarity. RKJ}

Always count on d_e to remember bypassing, :-). I never liked using those silly whiteboards
for prototyping.

Guys, thanks again for the support.

I have one question as I'm getting a little confused. Can someone draft up a simple schematic on how I should hook this up, with the mention of 100pf caps in AVcc etc, low pass filters on the TX and or RX lines... etc.

I'll also try moving the files to different folders as suggested.

I'll also order up the components to assemble Roberts PCB to see if the issue is with the breadboard... but that might be a while as funds are limited at the moment.

For what they are... basically modeling a small circuit at low speeds and low power < 1W they are useful however until one really learns the limitations, High interconnection (pin to pin) capacity. Noisy, Dirty and intermittent connections (I recommend a marine lubricant called LPS) and relatively high supply rail resistance > 1 ohm...
Keeping that in mind, When a circuit works put it in place on a proto shield, re test it carefully to verify that the breadboard values are the real values and go on to the next part. Breadboards aren't meant for permanent and complete projects, they are a medium for Modeling a limited subset of electronics with the understanding that the results may be dependent on values used to compensate for the effects of the breadboard. This includes but is not limited to High Speed anything. Breadboards become real 'unusual' at speeds above 50 MHz. Low Noise anything. dealing with millivolt levels on a breadboard is problematical from several standpoints. High Voltage anything. Any voltage greater than 25 V should be avoided or put on a separate breadboard with HV isolation and finally RF anything including antenna connections, Especially antenna connections.
Finally, LCD backlight currents are really too big for connection to a power rail except at the same place the power does. This helps to avoid the voltage drops caused by the backlight current.
I need to repeat that again because of the structure and properties of a breadboard, twice as many bypasses as would be required on a finished PCB type of construction and this includes soldered proto boards too might not be enough. It's easy and virtually free to put down the footprints in the final PCB design, A little testing will tell you which ones are needed and which are optional.

Bob
{Edit: Funny thing wuz that it all made sense... when I wrote it. RKJ

The 2 minimum bypasses are 100nF, .1 uF capacitors one from Vcc to ground and one from AVcc to ground close to the chip which at least on the 28 pin devices are across from each other so a 100nF/.1uF cap across pins 7 and 8 (Vcc) and 20 and 22 (AVcc). Adding a 10 to 22 uF cap couldn't hurt... Unless you put it in backwards... Messy and stinky, that.

Bob