Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
jrseattle
PostPosted: Oct 29, 2008 - 05:42 PM
Wannabe


Joined: Aug 24, 2006
Posts: 89


Dear AVRFreaks.

I was able to get my hands on some Atmega328p chips but am finding out that I cannot program them in parallel mode using the Atmel tools.

I am using a fixture using Wizbang Design adapter boards (http://www.wizbangdesigns.com/10018_10019_PCB.html) which works great for Atmega168 chips.
According to Atmel support, the device connections for the Atmega168 and Atmega328p are identical. This fixture has worked flawlessly for the Atmega168.

However, both AVRStudio and the avrdragon.exe program return incorrect Signature Bytes when programmed in parallel mode. Flash verification also fails, every time, tested on 5 chips.

Doing the same tests on the same chips in ISP mode (using a different fixture with the same dragon) works every time.

I'll be using ISP mode for now but hope this will get fixed by Atmel soon (I have an open support case)

Here is a log file:

C:\Electronics\DutchtronixClock\Version 3.5\test>dragonverify.cmd

C:\Electronics\DutchtronixClock\Version 3.5\test>rem "c:\Program Files\Atmel\Avr Tools\avrdragon\avrdragon.exe" -dATmega328p -mp -vf -if "..\..\ScopeClock.hex" -F 0xD2FF -G 0x
FD -L 0xEF

C:\Electronics\DutchtronixClock\Version 3.5\test>"c:\Program Files\Atmel\Avr Tools\avrdragon\avrdragon.exe" -dATmega328p -mp -s
avrdragon.exe v1.0.0 Copyright (C) Atmel Corporation 2006
Signature bytes: 0xff 0x95 0x0f.

C:\Electronics\DutchtronixClock\Version 3.5\test>if errorlevel 14 goto error

C:\Electronics\DutchtronixClock\Version 3.5\test>rem goto done

C:\Electronics\DutchtronixClock\Version 3.5\test>rem :error

C:\Electronics\DutchtronixClock\Version 3.5\test>"c:\Program Files\Atmel\Avr Tools\avrdragon\avrdragon.exe" -dATmega328p -mp -vf -if "..\..\ScopeClock.hex" -F 0xD2FF -G 0xFD -
L 0xEF
avrdragon.exe v1.0.0 Copyright (C) Atmel Corporation 2006
Verifying FLASH: 100.0%
FLASH verification failed.

C:\Electronics\DutchtronixClock\Version 3.5\test>if errorlevel 10 goto error

C:\Electronics\DutchtronixClock\Version 3.5\test>REM FAILURE

C:\Electronics\DutchtronixClock\Version 3.5\test>pause
Press any key to continue . . .

-Jan-
www.oscilloscopeclock.com
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Oct 30, 2008 - 07:24 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22832
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Which version of Studio do you use? And why do you want to use parallel mode unless you have messed up the fuses?

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
jrseattle
PostPosted: Oct 31, 2008 - 02:07 AM
Wannabe


Joined: Aug 24, 2006
Posts: 89


Hi, John.

I was using the official release of Studio 4.14 and updated to SP1 (build 603) but it made no difference.

Using the Dragon with a fixture like this is a very efficient way to program multiple AVRs in batch mode. I do this for my scope clock kits.

As I mentioned, I made a temporary fixture (breadboard, ZIF socket, xtal, capacitors) to do the same in ISP mode but it's just a bit more cumbersome and kludgy. Besides that, it's supposed to work, isn't it?

No reply from Atmel on this one.

jrseattle
www.oscilloscopeclock.com
 
 View user's profile Send private message  
Reply with quote Back to top
jrseattle
PostPosted: Nov 24, 2008 - 08:53 PM
Wannabe


Joined: Aug 24, 2006
Posts: 89


Just a quick update. Here is the latest email I received today from Atmel re. my support ticket:

I'm very sorry, I'm not able to find out what is wrong. I beleive it may be better to let someone with more experience handle this.

I don't even know if the anonymous sender was able to reproduce the problem. Not having High Voltage parallel programming available is definitely a problem. I have several brand new Atmega328p chips that cannot be programmed in ISP mode. Let's hope there isn't a larger problem.

jrseattle
www.oscilloscopeclock.com
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 24, 2008 - 09:00 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22832
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
I don't even know if the anonymous sender was able to reproduce the problem.
I guess they don't have your equipment and dont' really want to know Sad

So, are you using command line instead of the Studio programming interface? I don't have any 328s so can't do any testing myself with the Dragon.
Quote:
Not having High Voltage parallel programming available is definitely a problem.
Why is that? Are you using the reset pin in your design?

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
jrseattle
PostPosted: Nov 24, 2008 - 10:36 PM
Wannabe


Joined: Aug 24, 2006
Posts: 89


My equipment used for this particular situation is simply the AVR Dragon with a ZIF socket on the prototype area and parallel programming connections as described in the SCKT3200D2 connection sheet. This equipment works flawlessly for the Atmega168.
I'm using this setup to preprogram the Atmega328p chips for kits. The advantage of doing parallel programming is that you don't need a working circuit to program the chips; it's convenient and reliable.

To work around the lack of parallel programming I created a temporary circuit with just a crystal, 2 capacitors and the required ISP lines (CLK, MISO, MOSI, RESET) plus power of course, all connected to the Dragon. ISP programming works most of the time but some chips just fail to be programmed. Normally, I would check the fuses or reset the chip in parallel mode, but it's not available reliably.

I normally use the command line version (avrdragon.exe) but the same issue happens with Avr Studio.


jrseattle
www.oscilloscopeclock.com
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Nov 24, 2008 - 11:32 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 29284
Location: Wisconsin USA

Quote:

I'm using this setup to preprogram the Atmega328p chips for kits. The advantage of doing parallel programming is that you don't need a working circuit to program the chips; it's convenient and reliable.


Quote:

To work around the lack of parallel programming I created a temporary circuit with just a crystal, 2 capacitors and the required ISP lines (CLK, MISO, MOSI, RESET) plus power ...

OK, I'll bite: 1) Why do you need crystals/clock to program new chips? 2) How many less/more connections is that than HVPP? 3) Isn't putting the chips into the ZIF socket for pre-programming a wash between the different methods?

That still doesn't mean that HVPP shouldn't work, I guess. [We've never yet done HVPP for whatever reason.]

Lee
 
 View user's profile Send private message  
Reply with quote Back to top
jrseattle
PostPosted: Nov 25, 2008 - 01:23 AM
Wannabe


Joined: Aug 24, 2006
Posts: 89


Maybe I am mistaken here, but to program an AVR in ISP mode, it needs to be running. Since I am programming the fuses to use the crystal (my clock runs at 20 Mhz), the circuit needs a crystal to continue running after changing the fuse.

The other requirement is that the ISP circuit needs a 5V power supply, not a big deal but yet another requirement.

HPVV requires more connections but I already have this permanently wired jig which I can plug in to a Dragon with no other requirements (see picture above). Believe me, this jig and the proper batch files make it really easy to program a bunch of chips.

I'm surprised that the Atmega328p cannot be programmed reliably in HVPP mode and that Atmel doesn't seem to take this seriously. I guess I'm hoping that someone from Atmel sees this post Smile

jrseattle
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Nov 25, 2008 - 03:59 AM
10k+ Postman


Joined: Feb 19, 2001
Posts: 29284
Location: Wisconsin USA

Quote:
Maybe I am mistaken here, but to program an AVR in ISP mode, it needs to be running.

Actually, all ISP operations are done in reset. But there does need to be a valid clock source.

Quote:
The other requirement is that the ISP circuit needs a 5V power supply, not a big deal but yet another requirement.


No, it needs a valid Vcc level such that ISP can be carried out. Most normally, this would be a supply voltage within the range given in the datasheet. "Yet another"?!? Now, there is where HVPP becomes less atractive--the HV part. On your Dragon you have a ready source of "Vcc", but the 12V requirement is onerous. Wink


Quote:
Since I am programming the fuses to use the crystal (my clock runs at 20 Mhz), the circuit needs a crystal to continue running after changing the fuse.

Not exactly. You said earlier
Quote:
I'm using this setup to preprogram the Atmega328p chips for kits.
Normally, a full ISP sequence will perform fuse bit write and verify and then lock bit program and verify. Atmel has addressed your situation for "pre-programming" AVRs--the fuses are latched at the beginning of the ISP sequence and then the new value is invoked according to the datasheet. So, no, there is no need for crystal to do an ISP run at a virgin chip.

I don't see why ZIF/ISP isn't equivalent to your ZIF/HVPP as a way to "program a bunch of chips". Now, we use ISP truly "in-system"--something you might consider. And you are free to program whichever way you see fit. But I don't see a clear-cut advantage for HVPP in:

--ZIF insertion/removal -- a wash.
--12V HV vs. normal Vcc level--advantage, ISP.
--Connections: about the same number. If anything, advantage, ISP.
--Batch files: available for either.
--Programming speed: Hmmm; no data. Probably roughly equivalent. I suspect it is dwarfed by chip insertion/removal time.

Lee
 
 View user's profile Send private message  
Reply with quote Back to top
jrseattle
PostPosted: Nov 25, 2008 - 06:53 AM
Wannabe


Joined: Aug 24, 2006
Posts: 89


Hi, Lee.

Thanks for the explanation re. the programming without a crystal. I had to set the ISP frequency to something low in the batch file too but then I was able to program + verify both the flash and the fuses simultaneously without using a crystal. Once done, you can't access the AVR anymore, as expected. Learned something new, thanks.

However your comparison using the AVR Dragon misses one thing: The Dragon provides the 12V itself; no need for an external 12V supply.

I know the Dragon can provide Vcc to a circuit but I've been reluctant to use it, in case a short in the circuit would damage the Dragon. However, even when using it, it would mean another cable (the 6 pin ISP cable on the Dragon carries no power; it will only sense power in the circuit).

Programming speed/verifying speed at 125000Hz is actually not that fast but not an issue.

For my current situation (AVR Dragon with a Wizbang Design adapter board) the HVPP method has the advantage because Power (12V and Vcc) and connections are all done on board. ZIF, batch files, speed are all a wash.

However I realize I could wire another Wizbang Design adapter board for ISP programming and it would all be a complete wash. I'm currently using a temporary breadboard circuit, hoping that Atmel will fix this problem soon.

jrseattle
www.oscilloscopeclock.com
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 25, 2008 - 07:19 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22832
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
I know the Dragon can provide Vcc to a circuit but I've been reluctant to use it,
I'm confused. The Dragon does supply power to the chip only wether HVPP or ISP.

The internal 1MHz oscillator supplies the clock for programming everything and the fuses would be the last thing to program.

I do program M8 on a zif socket mounted to a bit of veroboard (pre-Dragon set up), never even thought about the clock not being present as I use the Auto program facility and the fuses are the second last thing programmed before the lock bits. (so the latch theory must be true...not that I would ever doubt Lee Smile ))

Anyway I'll need to order some M328s now to satisfy my curiosity but I'll use the STK500 as I don't want to mess around with the Dragon. See if the same problem exists.

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
hockeyrink
PostPosted: Mar 16, 2009 - 06:34 PM
Newbie


Joined: Apr 19, 2004
Posts: 1


What a crazy beast. I'm using an STK500 to program Arduino bootloaders onto the '168, and it'll do the 328p as well.

For a test, I set up the dragon (wow - lots of jumpers), and YES, '168 bootloaders load, but the 328p fails. I just updated the AVR Studio & did a firmware update for the Dragon (just in case), and still no joy. Keeps coming up with a signature comparison error and memory address error (yes, I didn't forget to change the part-type I was programming).

Peculiar - I was really hoping to move to the Dragon to do this parallel programming of the '328p.

Any luck on your side?
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Mar 16, 2009 - 08:24 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22832
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
to do this parallel programming of the '328p.
Why do you want use parallel programming? Did you mess up the fuses?

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
jrseattle
PostPosted: Nov 11, 2009 - 04:34 AM
Wannabe


Joined: Aug 24, 2006
Posts: 89


It's been a year since I posted this problem, time for an update.

Unfortunately, the problem has not been fixed. I'm using AVR Studion 4.18, build 682, and the Atmega328p cannot be programmed in parallel (HV) mode using the AVR Dragon. Same symptoms: bad signature and incorrect flash programming. ISP mode programming works on the Dragon. Both ISP and HV mode work on the STK-600.

To answer John's question: I want it because it is supposed to work. Normally, I can use ISP programming and all is well, but for that one time when something is really wrong, HV programming is handy - but it doesn't work on the Dragon. Don't count on this safety valve.

It is interesting to observe that in the device sheets listed under the Tools help section of AVR studio, the Atmega328p is not included under devicesheet SCKT3200D2, where it belongs (as I understand). I cannot find it elsewhere either.

I guess I could submit another bug report but since my previous report was ignored, it seems hardly worthwhile.

jrseattle
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 11, 2009 - 06:28 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22832
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

It seems that the new (or maybe even the old) Dragon docs is a bit messed up. The list shows SCKT3200A2 but when one clicks on the link it brings up SCKT3200D2. Confused A2 does not even seem to exist on the Dragon but it does on the STK500. Go figure.

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits