Go Down

Topic: atmega1284 programming from a 328 chip (Read 4 times) previous topic - next topic

malc-c

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 :(

oric_dan


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.

malc-c

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

malc-c

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

Quote

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

cyclegadget


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.

Go Up