AVR Doper problem (HV mode doesn't work)

Tim · Post by **Tim** » Thu Apr 12, 2007 3:10 am

Hello,

AVR Doper is a really great tool, thank you!
I'm using it in serial port mode and ISP programming works fine.

But HV mode doesn't work at all. The cathode of D3 just has ~4,5V. I'm not sure how exactly they're generated.

And another question, what about a base resistor for T4?

Guest · Post by **Guest** » Thu Apr 12, 2007 3:37 am

ok, I fixed the 12V problem (now I have 12.03V), now I have shot impulses on all pins (SPI, SPII, HVSPVCC, RESET). But the target µC (ATtiny13) doesn't return anything on SDO. The µC is working fine in ISP mode.

It's the first time I try using HV mode, anything special?

Post by **christian** » Fri Apr 13, 2007 7:56 pm

First of all: The base resistor of T4 is the internal pull-up resistor of the port pin.

I must admit that we have not tested HV programming with too many chips, I only have the ATTiny45 and an AT90S2343 available.

If I remember correctly, somebody here in the forum has reported problems with the ATTiny12, so it's possible that the Tiny13 does not work either.

If you have the resources in time and skills, it would be great to find out why it fails. Atmel's HVSP docs are a bit confusing. Look at the functions in hvprog.c and the comments in this file. The code unifies HV serial AND parallel programming, althogh parallel programming is not yet implemented.

In order to understand the code in this file, you should know how to read HVSP bit streams. These bit streams run into shift registers which then represent the pins for HV parallel programming. The association of bits in the bit stream to HV parallel mode pins is documented in a comment in that file. The hvspExecute() routine performs the mapping from an abstract parallel programming interface to HVSP.

Guest · Post by **Guest** » Sat Apr 14, 2007 10:03 am

Don't have that many tiny types available right now, but I tested it with a tiny25 and it doesn't work too.

borrowed my logic analyzer to a friend, once I'll get it back I'll investigate the signal.

Post by **christian** » Sun Apr 15, 2007 2:40 pm

The Tiny25 is almost the same as the Tiny45, except memory sizes. Since we have tested with the Tiny45, I would expect that it works.

Since you say that it also fails with the Tiny25, it's likely that something is wrong with the wiring.

duni · Post by **duni** » Wed Sep 05, 2007 1:07 am

My programmer also fails on tiny45. The uC has still it's default fuses and not programmed flash. I can't read the signature, it seems that the communication is there but something isn't quite right.
When the uC is in the socket I get an error:
Device signature = 0xffffff
When I measure the signals the signature is random - for example
Device signature = 0x3f3fff
Device signature = 0x3f3f3f
and so on...
If I get pins 2 and 3 (the clock) out of the socket the random signature occurs even without connecting the measuring instruments. If the uC isn't connected at all I get
Device signature = 0x000000
Do I have to change the fuses first via ISP to something that suits the doper's hvsp settings or what seems to be wrong?

duni · Post by **duni** » Sat Sep 08, 2007 2:31 pm

I'm still trying to fix my problem and I've done the following so far:
- I've rearranged the I/Os of the atmega8 and rebuilded the firmware and hardware to ensure there are no broken IOs
result: No success, everything works the same way.
- I've analyzed the SCI, SII and SDO signals via tha parallel port. It's fast enough to detect the basic activity, but not enough for further analysis.
result: The SII and SCI pins are synchronized - both signals start and stop at the same time. But the SDO signal is active (target sends data) about 14.5-15.5 ms before them, then it goes low and is no more active. As far as I can understand from the datasheet the SDO signal has to be active when there is clock on SCI, starting at the rising edge. I suppose there could be too much delay between the reset/vcc and entering the programming mode.
So: @christian - Since you've tested tiny45 successfully in HVSP what parameters in avrdude.conf did you use? Or did you use avrdude at all or something else?

edit: In the next days I plan to test the doper with a fast logic analyzer at work to record the exact SDI, SII, SDO, SCI, Reset and Vcc behavior. I hope I could get some help then, since that is the best I can do on hardware debugging side.

Post by **christian** » Sun Sep 09, 2007 5:56 pm

I don't think that you need a logic analyzer. You can easily slow down the clocks in hvsp.c/hvspExecute() by inserting delays.

I had no problem flashing a Tiny45 with avrdude so far. Either you have a newer chip revision which introduces an incompatibility or you experience some kind of hardware problem such as ringing or other physical effects.

Or, a final possibility: The serial output is done in a loop written in C. If gcc 4 does different optimization, it might have changed the order of instructions and thus the timing. Have you checked with gcc 3 or can you compile hvsp.c to assembler (with gcc option -S) and mail me the output to the support address?

Since I can't reproduce the problem here, it's really hard to come up with a fix.

duni · Post by **duni** » Mon Sep 10, 2007 4:26 pm

Here are 6 logic records after the execution of
avrdude -c stk500hvsp -P avrdude -p t45
I post them as links because the images are too wide.
http://lh5.google.com/duni.bg/RuVPVUziEbI/AAAAAAAAAJk/Bk3N4R_EbV4/prb1.PNG
http://lh6.google.com/duni.bg/RuVPVkziEcI/AAAAAAAAAJs/NS1JItVRdIE/prb2.PNG
http://lh6.google.com/duni.bg/RuVPVkziEdI/AAAAAAAAAJ0/26Ye8uyQRX0/prb3.PNG
http://lh6.google.com/duni.bg/RuVPVkziEeI/AAAAAAAAAJ8/Gb8nnf5iJgI/prb4.PNG
http://lh6.google.com/duni.bg/RuVPVkziEfI/AAAAAAAAAKE/sJyz8IyTKqY/prb5.PNG
http://lh3.google.com/duni.bg/RuVPZ0ziEgI/AAAAAAAAAKM/mDSqJv0eIjM/prb6.PNG

or you can view them before you download them at
http://picasaweb.google.com/duni.bg/Temp_uploads/photo#5108576580102394290

I've also flashed an old firmware(2007-03-29) and got the same result in hvsp.
I've not compiled it with gcc3 yet, but I will do that for the file you pointed out.
My toughts:I'm really not familiar with the hvsp-protocol but the SDO behavior of the chip is very strange - why does it have to go high for that long? That's why the programmer reads the signature as 'ffffff', I suppose. But in the second part, after this long high period, it seems that it sends proper data.
The Serial Instructions are strange, too - I don't see any pulses, only long high and low periods, but maybe the bytes to be send are like that?
note:
1.the signals indicate the tiny45 pins, so that SerialDataOut means that t45 sends data(as in the datasheet).
2.Although 'Ch3' and 'Channel 7' are active in prb1.png, they are not used.
3.Sometimes google gives '403 Forbidden' when opening the images. You can still view and download them in the gallery.

I hope, that this logs give you some usable information on the problem.

Post by **christian** » Tue Sep 11, 2007 11:59 am

The logic signals look perfectly OK on the first glance.
When you look at the clock signal (SCI), you can see the end of a byte at the two short pulses. You can also see delays (when SCI does not change level) which indicate that the AVR processes an interrupt, most likely a USB interrupt.

The data sent at SII should be that way. SDI looks reasonable, too. And we even receive data at SDO, which indicates that the target chip understood the command. SDO is at 1 for the first two bytes since the command is not yet sent at that time. Data is received only after the command has been clocked in.

I have not decoded the commands seen on these diagrams. But I don't see a reason why they should be wrong.

duni · Post by **duni** » Thu Sep 13, 2007 6:33 pm

Well, I'm excluding more and more possible problems and every time I come at a dead-end.
So far:
- since I've used the two latest pre-build firmwares and haven't build it with gcc4, this shouldn't be an issue.
- I've tried the programmer in AVRStudio 4 in CDC mode - everything - signature,lock bits, fuses and so on - reads as 0xFF.
- I have the F revision (what a coincidence :lol:

)- there is still no errata in the datasheet so I mailed atmel's support - they said, there shouldn't be a problem with the hvsp in this revision.
further concerns:
I've tried to decode the commands from the logic analyzer:
If I'm right the first and the third byte seem fine - 0x4C and 0x68. I read the second byte as 0x0C instead of 0x00 to 0x02. As far as I can see from the datasheet this is the command for the calibration byte. Well, I'm not hoping to be right, because if there was something only with the signature command the other things would read right.
Anyway I don't understand the fourth byte - the SDO answer from the target - why it copies the clock on the falling and rising edge instead to change only on the rising one. And why is it following the SII line? I don't understand that, I'm not saying it has to be wrong, but if you could just check it, it will be of great help to me, because I really don't know where else to look and what for.

I think I found it:(please tell me I did...)
As the atmel support pointed out after I send them the pictures and what I noticed with the simple parallel port analyzer - the reset pin goes high and stays high BEFORE VCC goes high, or the other way around: Vcc goes high EXACTLY at the same time as SCI and after Reset.
BUT as the datasheet says the proper order is:

1. Set Prog_enable pins listed in Table 22-13 to “000”, RESET pin and VCC to 0V.
2. Apply 4.5 - 5.5V between VCC and GND.
Ensure that VCC reaches at least 1.8V within the next 20 μs.
3. Wait 20 - 60 μs, and apply 11.5 - 12.5V to RESET.
4. Keep the Prog_enable pins unchanged for at least 10 μs after the High-voltage has been
applied to ensure the Prog_enable Signature has been latched.
5. Release the Prog_enable[2] pin to avoid drive contention on the Prog_enable[2]/SDO
pin.
6. Wait at least 300 μs before giving any serial instructions on SDI/SII.

edit: I'm just checking the hvspEnterProgmode function to see how it works and I notice the PORT_PIN_SET(HWPIN_LED). Is the led shining only on flashing or during the entire hvsp programming cycle, because I've never seen it on.

Post by **christian** » Thu Sep 13, 2007 10:00 pm

The LED reflects the "programming mode" status. It's on during the entire programming. If programming fails, you probably see a short flash at best, since things go so fast.

The function hvspEnterProgmode() definitely enables Vcc 40 microseconds before setting Reset to high voltage. See hvprog.c for the implementation.

One other question: Did you use a 74HC126 or a 74LS126? The LS type has a low impedance and may change logic levels! You need the HC type.

duni · Post by **duni** » Thu Sep 13, 2007 10:48 pm

The function hvspEnterProgmode() definitely enables Vcc 40 microseconds before setting Reset to high voltage

... yes I saw it, and my genius idea felt apart, because I forgot, that I had triggered the SDO line, so the record starts when it goes high. I don't know why I don't see that on the reset line, but that doesn't mater... everything should be fine at that part.
I use 74HC126GAP. But that only affects ISP, doesn't it? and ISP is working like a charm. I've successfully programmed some tiny45s. although they are dead for the ISP now, because I need the reset pin.
I unprogrammed the clock divider, so that the test target runs at 8Mhz.
again the dead-end.
What about the SDO answer? Well if you say that it's fine too, I'll buy new components, new board, etch it and solder them again :evil:

. (just kidding)

One question on my side: does the avrdude -B option work for the programmer, I mean can I set the SCL period with it and analyze at low frequencies, or is this possible only by inserting firmware delays?

Post by **christian** » Fri Sep 14, 2007 1:10 pm

First of all: Have you checked the programming voltage of 12 V on the RESET pin? And the -B option does not influence the HVSP clock, only the ISP clock. You would have to insert delays in the firmware.

I've checked with avrdude and my ATTiny45 (it has the number 0613, don't know which revision this represents). In debug mode, I see the following commands:

Code: Select all

$avrdude -c stk500hvsp -P avrdoper -p attiny45 -vvv
[...]
avrdude: stk500hv_read_byte(.., signature, 0x0, ...)
avrdude: stk500hv_read_byte(): Sending read memory command:
avrdude: stk500hv_read_byte(.., signature, 0x1, ...)
avrdude: stk500hv_read_byte(): Sending read memory command:
avrdude: stk500hv_read_byte(.., signature, 0x2, ...)
[...]

As you can see, the first thing which is read is signature byte 0. OSCCAL and signature byte 0 are very similar, only the highbyte/lowbyte selector differs.

Did you run avrdude with the -vvv option to see which commands it INTENDED to send?

Regarding SDO: I don't know why it changes on both edges either, but I can't remember how it was meant to be. As long as it's stable and correct where it is sampled (after one of the two edges), I don't see a problem here.

duni · Post by **duni** » Fri Sep 14, 2007 1:28 pm

Code: Select all

avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00s
avrdude: stk500hv_read_byte(.., signature, 0x0, ...)
avrdude: stk500hv_read_byte(): Sending read memory command: Send: 8 bytes: 1b 0d 00 02 0e 3b 00 21  ".....;.!"
Sending 8 bytes data chunk
Received 29 bytes data chunk of total 9
Receive: 1 bytes: 1b  "."
Receive: 1 bytes: 0d  "."
Receive: 1 bytes: 00  "."
Receive: 1 bytes: 03  "."
Receive: 1 bytes: 0e  "."
Receive: 1 bytes: 3b  ";"
Receive: 1 bytes: 00  "."
Receive: 1 bytes: ff  "."
Receive: 1 bytes: df  "."
avrdude: stk500hv_read_byte(.., signature, 0x1, ...)
avrdude: stk500hv_read_byte(): Sending read memory command: Send: 8 bytes: 1b 0e 00 02 0e 3b 01 23  ".....;.#"
Sending 8 bytes data chunk
Received 29 bytes data chunk of total 9
Receive: 1 bytes: 1b  "."
Receive: 1 bytes: 0e  "."
Receive: 1 bytes: 00  "."
Receive: 1 bytes: 03  "."
Receive: 1 bytes: 0e  "."
Receive: 1 bytes: 3b  ";"
Receive: 1 bytes: 00  "."
Receive: 1 bytes: ff  "."
Receive: 1 bytes: dc  "."
Reading | #################                                  | 33% 0.02s
avrdude: stk500hv_read_byte(.., signature, 0x2, ...)
avrdude: stk500hv_read_byte(): Sending read memory command: Send: 8 bytes: 1b 0f 00 02 0e 3b 02 21  ".....;.!"
Sending 8 bytes data chunk
Received 29 bytes data chunk of total 9
Receive: 1 bytes: 1b  "."
Receive: 1 bytes: 0f  "."
Receive: 1 bytes: 00  "."
Receive: 1 bytes: 03  "."
Receive: 1 bytes: 0e  "."
Receive: 1 bytes: 3b  ";"
Receive: 1 bytes: 00  "."
Receive: 1 bytes: ff  "."
Receive: 1 bytes: dd  "."
Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

I'm checking the debug output once in a while, but I don't see nothing suspicious. The received byte before the last one should be the signature byte, I suppose.
You can see the revision on the bottom of the uC. 0613 means 2006, 13th week as far as I know. This number is found on the bottom right under the revision letter on the reset pin side.
The next thing I'll do is to get hold of an old tiny45/25 to check if it works.
Btw. are the avrdude commands sending the right bytes?
And what version of avrdude are you using, because you have identified the target as attiny45, and in the 5.3 & 5.4 it's t45?