atmega1284 programming from a 328 chip

Can't see the schematic, try again?

Do have DTR connected as well? If not, you'll need to press Reset after the "Binary sketch size" message comes up.

Lets see if this works

ignore the ISP connections, I've just used the serial connection shown

and yes I've tried DTR connected via the 0.1uf capacitor, and without - It doesn't get that far to reset the chip

Hi Crossroads Could I use my JTAGICE that has a ISP 6pin connector to program a bootloader into a ATMega1284p? Would I use the Aduino IDE or AVR Studio 4.18? How does this chip fair as an Arduino say with the SPI system for the W5100 ethernet controller. I ordered a few of these from Mouser. I also have a STK500 also I could use with a 16Mhz crystal too. Don

I don’t know what is involved with using JTAGICE to program via ISP. This came up in another thread recenly, outlook was not good.
I use Atmel AVR ISP MKii myself, thru the IDE. Have to find the IDE driver here for it:

Its an 8-bit AVR, so would fair as well as the others for W5100 ethernet controller.

@malc-c

What FTDI are you using? Also, it is possible you have the RX and TX swapped. It will not hurt anything to try swapping those leads.

cyclegadget: @malc-c

What FTDI are you using? Also, it is possible you have the RX and TX swapped. It will not hurt anything to try swapping those leads.

It's a sparkfun FT232 Brakeout board. It worked fine with the original 328P, and I've also tried swapping the TX and RX lines over. I get pulses on the TX / LX leds, its as if the software is sending a request to upload the data, but not receiving the Ok to send it. I'll strip the breadboard and re-wire it just in case I've missed something (I seem to remember I had a similar issue with the 328P until I tied one of the voltage reference pins to supply.)

Well after spending most of my time sorting out the arrangements following a bereavement in the family I have been able to spend a few hours trying to get the 1284P to talk with the PC and upload a program. But to no avail.

Just to prove that the FTI breakout board was working fine, I breadboarded the 328P chip I received off e-bay, and could upload the blink and fade exampled with no issue. Breadboarded the 1284P and hooked up the FTI board - no matter what board I select from the dropdown option I get the attached error.

Looks like I’ll have to have a re-think on my project to see if I can do all the control I want using the 328P :frowning:

malc-c: ignore the ISP connections, I've just used the serial connection shown

and yes I've tried DTR connected via the 0.1uf capacitor, and without - It doesn't get that far to reset the chip

If this is board, it appears to provides 3.3V be default, not 5V, https://www.sparkfun.com/products/718

You definitely need to have the DTR wired via 0.1uF cap to do the proper reset. You also need to have the Rx,Tx pins swapped as shown in your schematic, if using a regular FTDI cable or FTDI Friend. For the sparkfun board, you just have to be certain the signals flow in the correct directions.

I always use 1K resistors in Rx,Tx lines in case of mistaken cross-wiring.

Thanks for the reply. The Sparkfun board has a means of running at 5v (basically de-solder a link and bridge the two pins ( https://forum.sparkfun.com/viewtopic.php?f=15&t=21234 )

Like I said, it works fine when using the normal 328P with the uno bootloader. It looks to me as if the optiboot isn't talking the same language or at the same speed ! - hence the protocol error

Bit more googling and it seems to be due to resetting too soon. I found this regarding the error - OK it's related to programing the 328... but my guess it the same thing happening with the 1284P

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.

Just need to find a way of resolving it

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 ;-)

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, :-).