Problems with programming ATmega1284P

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all, while I've been lurking the forums for a while I've never posted anything here before. While I'm still a beginner I have some experience with programming AVRs.
So I have a project where I'm using an ATmega1284P/PU1536 chip. Everything has been going quite OK but since I accidentally broke one of the legs while removing the MCU I had to order a new one. I ordered from Digikey what I thought was the same model but turned out to be ATmega1284P/PU1730 and after hours of googling and reading datasheets I'm nowhere near any conclusion. 
I can't get my program to work with the new ATmega but it runs fine on the old one. It programs the chip but nothing seems to work.

My setup is Atom with PlatformIO and I have the USBasp programmer to write to the chip via ISP. 

I write the code in C/C++/Wiring and use the mightycore core to use Arduino's libraries and Adafruits.
My code is here: https://pastebin.com/bicUSiDB (sorry for the Icelandic in comments)

 

Is there any difference that I'm unable to find information about between those two chips?

 

Best regards, Sam
 

 

 

This topic has a solution.

Last Edited: Wed. Apr 18, 2018 - 03:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The difference between the two chips is the date code (YYWW (year, week)).

 

My guess is there is a difference in fuse settings between the old and new chips.

 

 

EDIT: typos

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

 

Last Edited: Tue. Apr 17, 2018 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A clear picture of your setup would be helpful!

Why not start with an Arduino Uno or Mega, or nano if breadboarding?

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:
The difference between the two chips is the date code (YYWW (year, week)).
fyi, assembly of mega1284P in DIP moved to Microchip Thailand in 2017-Dec (after 1730)

http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=atmega1284p

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:

The difference between the two chips is the date code (YYWW (year, week)).

 

My guess is there is a difference in fuse settings between the old and new chips.

 

 

EDIT: typos

 

Thanks! That makes me less worried that I have a mismatching chip. I'll check with the fuse settings, although I haven't messed with those on the AVR (have done so on a PIC) it brings me to a point to look for problems. Thanks again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

ki0bk wrote:

A clear picture of your setup would be helpful!

Why not start with an Arduino Uno or Mega, or nano if breadboarding?

 

Jim

 

 

I've already advanced from using the breadboard to a fully built pcb. 

Attached is the prototype board.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samuelhj wrote:
I've already advanced from using the breadboard to a fully built pcb.

Nice looking project, one thing, I don't see any bypass caps, 100nf on the VCC/GND pair, or the AVCC/GND pair, perhaps they are on the bottom of the board....

 

Jim

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JTAG is enable by default, this will use some pins on PORTC and may cause problems with its use, disable jtag fuse if you are not using it for debug.

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do report back on whether its a Fuse issue or not, that was my first guess, also.

 

So, I have to ask, what is the long black thing with the threaded connector?

 

The weatherproof wire pass through needs a rubber gasket, (or two?), to truly be watertight.

I can't tell from the photo if you have one installed or not.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still working on the fuses, really don't want to mess this up so I'm reading into it. 
The black thing is a MPX5700 pressure sensor to read pressure from the solenoids (it's an automatic tire monitor system that inflates/deflates tires).
The device (as of yet) isn't waterproof. I'll have to redesign the housing for that. I just had couple of those PG pass throughs lying around so I used it to protect the wires. (There's also supposed to be a cable with 7 wires that runs through the same pass through that controls the solenoids)

 

I found this fuse calculator on line http://www.engbedded.com/fusecalc

But I'm not quite sure what the values should be 100%
I have a 16MHz external clock.
BOD is set at 2.7V
JTAG off
But the calculator only shows 8MHZ external clock. 

 

I guess I'm back at reading through the datasheet. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After reading the fuses from the old chip and programming the same fuses to the new chip, it still does nothing.
I've also replaced the chip in case it was a faulty chip and that changed nothing either. The original chip still works fine if I put it in the circuit. 
I'm quite stomped at the moment.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

After hours of debugging I started wonder whether there was an RFI causing issues (Having a bit of experience in that field). (For development I've been just using a flat cable from the board to the display and it's worked fine).
So I made a small coil pickup for my scope and explored my work desk. Turning things on and off.
Of course the last thing I turned off was the lamp that illuminates my work desk. 
Turns out that the RFI from that said lamp has more impact on the ATmega1284P that I got than the earlier versions (I have no idea why).
So basically turning my worklamp off makes things work. (It's an ikea brand bulb in it).
Thanks everyone who replied so quickly.

 

Conclusion: Be sure fuses are correctly set and ensure no RFI is causing issues. 
The coil I made was just a short 20 wound ~0.1q wire around a 20mm ferrite I had lying around, connected to the scope via RG316 cable I had lying around. 
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent inadvertent EMC test.

The worklamp's bulb noise may be getting in via the power supply.

Per the AVR EMC app note, an inductor between power and AVR's Vcc.

If able, supply power to the AVR from a battery; if there's a wall wart, replace it with a battery.

Noisy USBasp power may be an issue.

 

Microchip Technology Inc

Microchip Technology

Application Notes

AN_1619 AVR040: EMC Design Considerations

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en590907

(page 13)

via https://www.microchip.com/wwwproducts/en/ATmega1284P

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's actually getting through the +5V supply to the LCD, through  the cable. I started measuring the AVR by it self with a scope with the cable unplugged and there was no interference. Maybe a status led for next design would be a good idea...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's actually getting through the +5V supply to the LCD, through  the cable.

That does look like a lot of cable.  How fast are you talking to the display?

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:

It's actually getting through the +5V supply to the LCD, through  the cable.

That does look like a lot of cable.  How fast are you talking to the display?

 

I'm not quite sure what the clock speed of the library is (ILI9341 from Adafruit) but it seems to be at 6MHz clock speed. The cable is about 30cm long. I knew I was stretching it at first but didn't think the new ATmegas would be so different from an old one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Try a much shorter cable (as a test), to see if that makes a notable difference.

 

How about a Vcc cap at either end of the cable, or both? 

If noise is on the data/clk, maybe 22pf-100pf would help, or even use shielded ribbon cable.

 

Make sure your clk/latch signals times are not too close to the data rise/fall---give them plenty of time to settle & widen your pulses.

I don't like spi sometimes, since the chip's goal is to make the edges as close as possible.  Insert some nop's, if possible to separate the edges (between data & clk/latch ) & give your self some wider pulses.

 

 

 

 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samuelhj wrote:
... but didn't think the new ATmegas would be so different from an old one.
fyi, final test of mega1284P in DIP is moving to Microchip Philippines.

Microchip Technology Inc

Microchip Technology

Product Change Notification - LIAL-09LSTS461 - 18 Apr 2018 - CCB 3331 Initial Notice: Qualification of MPHL as a new final test site for selected Atmel products available in 40L PDIP, 28L SPDIP and 20L PDIP packages.

http://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=LIAL-09LSTS461

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

 

Try a much shorter cable (as a test), to see if that makes a notable difference.

 

How about a Vcc cap at either end of the cable, or both? 

If noise is on the data/clk, maybe 22pf-100pf would help, or even use shielded ribbon cable.

 

Make sure your clk/latch signals times are not too close to the data rise/fall---give them plenty of time to settle & widen your pulses.

I don't like spi sometimes, since the chip's goal is to make the edges as close as possible.  Insert some nop's, if possible to separate the edges (between data & clk/latch ) & give your self some wider pulses.

 

I already had a 470uF cap at the VCC end on the display but added a 10nF cap as well, didn't seem to make much difference.
I now have more "final" design with a much shorter ribbon cable and a VGA like cable running to the display and that seems to have made the most difference. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

samuelhj wrote:
I've already advanced from using the breadboard to a fully built pcb.

Nice looking project, one thing, I don't see any bypass caps, 100nf on the VCC/GND pair, or the AVCC/GND pair, perhaps they are on the bottom of the board....

 

Jim

 

The VCC caps are hiding behind the ribbon programming cable and then there's one on the bottom side.. (yeah yeah.. I forgot)