I can update existing firmware on a 328 PU, but not write it to a new one

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

I use an amateur radio transmitter by QRP Labs called a U3S that comes with a pre programmed Atmega328P processor. The kit has the option of adding a 6 pin header to allow in circuit programming. I took this option and extended it to an RS232 port on the rear. Using a cheap Ebay USBasp I can read a pre programmed chip, and I can update its firmware successfully.

 

I bought, from RS Components, some new, seemingly genuine ATMEL 328 PU chips. If I install one in place of a pre programmed chip, the programmer cannot even see it. I have tried three fairly similar cheap programmers, all of which see and read / write pre programmed 328 chips just fine, but none see the new ones.

 

I have tried Extreme Burner and a Chinese app called progisp1.72  Neither software sees the new chips, but otherwise work with "factory" ones I am reliably informed there's no reason NOT to be able to write supplied code to a new chip, and others have successfully done just that.

 

. I am going to try AVRdude with AVRdudess GUI in a bit, but fear the worst as I suspect I am missing something. To be brutally honest the technicalities of all this are not of huge interest, I just want to write some spare chips to new 328 PU's :) How hard can this task be? ;)  Can anyone kindly and simply explain what my issue may be please? Thanks and a happy and healthy New Year to all.

This topic has a solution.

Best regards, Chris Wilson

Last Edited: Thu. Jan 4, 2018 - 11:23 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brand new AVR's usually run on a 1MHz internal RC oscillator.

This is so slow that most programmers hve to be slowed down to be able to set the fuses to a more sensible value.

With avrdude this is the "-b" command line option.

 

I'm not sure if this is your issue though. The chinese usbASP's are supposed to detect this and switch to a lower programming speed automatically.

There is also a "slow" jumper option on the usbASP boards.

 

How sure are you that the wiring is correct? ( & power supply decoupling cap's ...)

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

If the chips are true AVRs try slowing down your ISP clock frequency to say 50khz and try reading the parts. A factory AVR uses the internal oscillator and it is divided by 8 yielding a 1MHZ internal clock speed. 50khz should be fine to use as a test. If it works you will need to read the working parts fuse settings and program the new ones accordingly

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Success! Slowing it down a lot allowed me to force AVRdudess to "see" a new chip, which oddly it ID as a plain 328 and not a 328 PU as marked upon it. But it similarly ID a factory supplied 328 PU as a plain 328... That aside, it allowed me to set the fuse bits to match the OE one, and then to write the hex file. I then wrote the .eep file with my settings on it as well, and it seems to work. My only tiny worry is the QRP Labs people say the lock fuse should be 0xFF but reading an OE processor it's shown as 0x3F, and that's what left it at in the new chips. Is that an issue? It didn't seem to want to accept 0xFF and baulked at it.

 

MANY, MANY many thanks, I had been struggling with this for ages. Easy when you know how! Much appreciated and all the best!

Best regards, Chris Wilson

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

That  suffix can be a bit confusing. Mega328-PU is NOT the same as Mega328P. That P in the first number denotes a DIP package. In the second number, the P denotes "pico-power" features that were added to Mega328. So, what you have is a plain (that is, NOT pico-power) Mega328.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Jan 4, 2018 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrBasil wrote:
which oddly it ID as a plain 328 and not a 328 PU as marked upon it.

???  "Oddly"?  What do you expect?  What does the datasheet say?  Are there different signatures for the same chip in different packages?  No.  What does the -PU indicate?  Anything about the chip model?  No.  The P is the package type, and the U is the temperature range.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

jgmdesign wrote:

If the chips are true AVRs try slowing down your ISP clock frequency to say 50khz and try reading the parts. A factory AVR uses the internal oscillator and it is divided by 8 yielding a 1MHZ internal clock speed. 50khz should be fine to use as a test. If it works you will need to read the working parts fuse settings and program the new ones accordingly

Jim

 

Thank you to paulvdh and you, jgmdesign, seemingly I cannot mark both your replies as solutions, but indeed you were both spot on, thanks!

Best regards, Chris Wilson

Last Edited: Thu. Jan 4, 2018 - 11:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My only tiny worry is the QRP Labs people say the lock fuse should be 0xFF but reading an OE processor it's shown as 0x3F, and that's what left it at in the new chips. Is that an issue? It didn't seem to want to accept 0xFF and baulked at it.

Don't worry about it.  There are actually only 6 lock bits, and they're the lower 6 bits in the byte.  The two upper bits are "don't care".  Typically, they read (and should be written) as '1', but depending on the version of avrdude you have, the avrdude.conf file (which contains part definitions) may have gotten that wrong i.e. the unused bits are reported as '0'.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:

My only tiny worry is the QRP Labs people say the lock fuse should be 0xFF but reading an OE processor it's shown as 0x3F, and that's what left it at in the new chips. Is that an issue? It didn't seem to want to accept 0xFF and baulked at it.

Don't worry about it.  There are actually only 6 lock bits, and they're the lower 6 bits in the byte.  The two upper bits are "don't care".  Typically, they read (and should be written) as '1', but depending on the version of avrdude you have, the avrdude.conf file (which contains part definitions) may have gotten that wrong i.e. the unused bits are reported as '0'.

 

OK, that's great, thank you!

Best regards, Chris Wilson