v8 linuxspi won't connect - Reset Line Inverted ???

[PeterHouseJr]

My Python App Turns on the power, turns on the 3.3v-5v level shifter, waits 100ms, call AVRDUDE, turns off level shifter, turns off power:

Sends this command using subprocess:
command = 'sudo avrdude -n -p m328pb -c linuxspi -P /dev/spidev0.0:/dev/gpiochip0:26 -B 12kHz'

This command returns this to stderr:
Error: AVR device not responding
Error: initialization failed (rc = -2)

• the programmer ISP clock is too fast for the target
• use -B to set lower the bit clock frequency, e.g. -B 125kHz
• use -F to override this check

Here is the scope shot:

The connections are shown on the scope screen.
The Reset line is mostly low with a lot of high pulses.
Immediately BEFORE each reset pulse are four bytes, 0xAC 0x53 0x00 0x00, clocked out on MOSI.

Here is a close up of the four bytes and the first reset pulse. All reset pulses are preceded by the same four bytes.

You can see the reset line is mostly low (Active Reset).

A previous version, 6.3, of AVRDUDE worked fine on this hardware using this command:
command = 'sudo avrdude -n -p atmega328pb -C avrdude_gpio.conf -c linuxspi -P /dev/spidev0.0 -b 125000'

It works exactly the same whether a target is connected or not. The target is a mature product and programs correctly, with the same cable using an Atmel-ICE.

I believe the target is connected properly since I used this same hardware setup with AVRDUDE v6.3

The reset line seems to be inverted using AVRDUDE 8.0

Any help would be appreciated.

[MCUdude]

Can you try modifying your avrdude.conf file and invert the reset pin there, by adding a ~ in front of the reset pin number?

avrdude/src/avrdude.conf.in

Lines 862 to 869 in 0b92721

	programmer # linuxspi
	id = "linuxspi";
	desc = "Use Linux SPI device in /dev/spidev*";
	type = "linuxspi";
	prog_modes = PM_TPI | PM_ISP;
	connection_type = spi;
	reset = 25; # Pi GPIO number - this is J8:22
	;

[PeterHouseJr]

Thank you for the quick response!

I copied the avrdude.conf file from the installation folder and placed it in the current folder and added the -C parameter to use the local conf file and modified the conf as you suggested only using my pin ~26 and removed pin 26 from the command line where the port is specified:
command = 'sudo avrdude -n -p m328pb -C avrdude.conf -P /dev/spidev0.0:/dev/gpiochip0 -c linuxspi -B 12kHz'

programmer # linuxspi
id = "linuxspi";
desc = "Use Linux SPI device in /dev/spidev*";
type = "linuxspi";
prog_modes = PM_TPI | PM_ISP;
connection_type = spi;
reset = ~26; # Pi GPIO number - this is J8:22
;

The reset line is now inverted but still no MISO data.

Detail of One Reset Pulse

I have verified the voltage levels at the Target connector and all look good at the Target to Me. Tried multiple Targets and Not sure now why it does not work.

Any more ideas?

[mcuee]

Strange issue.

What about other avrdude official release versions? Say avrdude 7.3 and avrdude 7.2.

I have no issues using LinuxSPI with my Raspberry Pi 400 and ATmega328P.

[mcuee]

I tend to susepct there is a timing issue here.

My Python App Turns on the power, turns on the 3.3v-5v level shifter, waits 100ms, call AVRDUDE, turns off level shifter, turns off power.

[PeterHouseJr]

As shown in the scope shot:

1. Power is turned on, the level shifter is turned on.
2. The Reset line is taken inactive (high)
3. ~225ms pass
4. 4 bytes, 0xAC 0x53 0x00 0x00, are transfered to the 328PB with no response bytes returned (All 1s) by the target
5. The reset line is pulsed active (low) for ~50us
6. ~22ms pass
7. steps 4-6 are repeated ~66 times
8. ~25ms pass
9. the reset line is taken active (low)
10. ~10ms pass
11. The level shifter is turned off, the power is turned off.

Observations:

1. This is very slow -B 12kHz faster or slower yields the same results only different clock rate.
2. THe SPI clock should get a response from the target.
3. My targets all program using an Atmel-Ice in SPI mode using AVRDUDE 8.0 under Windows.
4. My targets all program using the same hardware connected to another Pi and AVRDUDE v6.3 - This is my reference platform and is used for production programming of my customers parts.
5. I use Tag-Connect cables for all programming. www.tag-connect.com.
6. I need v8.0 to read the serial number from the 328PB.

I will try (when I get in the office on Monday):

1. Connect Atmel-ICE to Pi using AVRDUDE 8.0
2. Verify MISO signal at target using scope analog channel.
3. Study the 328PB programming documents to verify the signal timing and programming command sequence.

I am hoping someone can look at this and either know this is correct signaling for the 328PB or know it is incorrect and tell me what it should be.

Thank you for everyone who has helped so far.

[PeterHouseJr]

Still having issues . . .

These two scope shots show the working Pi using avrdude 6.3. The first four bytes are the same: 0xAC 0x53, 0x00, 0x00 with the 328 returning 0xFF 0xFF 0x53 0x00 as shown in the second scope shot.

Zoom in scope shot showing first four bytes:

The Reset line should be low during the communication which I initially thought was wrong.

1. Stopped trying to connect AtmelICE to Pi since it does lead to my end game of using linuxspi (and did not immediately work).
2. The MISO signal never shows any activity when using AVRDUDE 9 as shown in the previous scope shots.

I do keep getting errors from AVRDUDE. but they seem innocuous or incorrect. For instance, the speed issue does not make sense to me.

`Try without specifying -B
:sudo ./avrdude_80 -v -n -p m328pb -C ./avrdude_80.conf -c linuxspi -P /dev/spidev0.0:/dev/gpiochip0 -U signature:r:TmpHex/sig.hex:i

Avrdude_80 version 8.0-20241010 (0b92721)
Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

System wide configuration file is /home/Peter/SDProg/avrdude_80.conf
User configuration file /root/.avrduderc does not exist
Warning: system wide configuration file version (@AVRDUDE_FULL_VERSION@)
does not match Avrdude build version (8.0-20241010 (0b92721))

Using port : /dev/spidev0.0:/dev/gpiochip0
Using programmer : linuxspi
Defaulting bit clock to 200 kHz
AVR part : ATmega328PB
Programming modes : SPM, ISP, HVPP, debugWIRE
Programmer type : linuxspi
Description : Use Linux SPI device in /dev/spidev*
Error: AVR device not responding
Error: initialization failed (rc = -2)

• the programmer ISP clock is too fast for the target
• use -B to set lower the bit clock frequency, e.g. -B 125kHz
• use -F to override this check

Avrdude_80 done. Thank you.
`
I have tried four -B options: 1kHz, 10kHz, 100kHz and no -B resulting in 6kHz, 10kHz, 100kHz and 166kHz respectively with the same error message. With no -B shows 200kHz as defult but the actual rate is 166kHz. The working unit runs at about 140kHz for comparison.

I copied the .conf file and the executable to my local directory in order to have the ability to change versions of avrdude for testing. I am working on getting avrdude 6.3 installed now alongside avrdude 8.0.

The exact same hardware works on another Pi running a previous version of Raspbian and avrdude 6.3 and run from a python script with a gui.

When I run the avrdude 6.3 executable, I get the following error: "bash: ./avrdude_63: cannot execute: required file not found". Probably since it is not installed and is missing libraries. Can two versions be installed at one time? Where can I get the 6.3 installer or source for compile? .github only goes back to 7 and I don't see v6.3 anywhere.

Any suggestions appreciated ! ! !

[PeterHouseJr]

Eureka ! Fixed ! ! Solved ! ! ! Working ! ! ! !

Here is the issue:

Working Scope shot using avrdude 6.3:

Non-working Scope shot using 8.0:

The only difference is the Reset line. During code setup before avrdude is called, the gpio lines are enabled and set in order to turn on power to the target, and also to turn on the target signal lines. I did not know the reset line had to be in the high state before calling avrdude.

After reading the AVR910 Application Note regarding Atmel ISP programming, it states: " Immediately after Reset goes active on the target AVR microcontroller, the chip is ready to enter Programming mode." In the non-working scope shot, the Reset line is active from the beginning of power on. I believe what is happening, is the 328PB is getting one or more SPI clock pulses after power on and before avrdude begins to communicate which confuses the 328PB and causes the SPI communication to lose synchronization resulting in failure. I am not sure why the repeated tries by avrdude do not work as I believe they should.

I do still have an issue with the warning messages from avrdude and do not know how to resolve them:

System wide configuration file is /home/Peter/SDProg/avrdude_80.conf
User configuration file /root/.avrduderc does not exist
Warning: system wide configuration file version (@AVRDUDE_FULL_VERSION@)
does not match Avrdude build version (8.0-20241010 (0b92721a))

Any insight to this would be welcome.

In retrospect, I should have looked at this earlier although the working unit was at my customer location and I had to get it back to the office for the side by side comparison. I also built an adapter board so I could keep the scope probe setup intact while easily changing programmers between raspberry Pis, the Atmel-ICE, and my Pickit5 programming hardware.

[stefanrueger]

@PeterHouseJr Thanks for reporting back and sharing how you solved this problem! Could I ask you to apply the following patch on git main and see whether that removes the requirement for keeping reset at high level before entering avrdude? I hope this makes AVRDUDE more robust against initial line setup.

diff --git a/src/linuxspi.c b/src/linuxspi.c
index 48573679..ba1da138 100644
--- a/src/linuxspi.c
+++ b/src/linuxspi.c
@@ -244,6 +244,12 @@ static int linuxspi_open(PROGRAMMER *pgm, const char *pt) {
     goto close_gpiochip;
   }
 
+  // Ensure the part is active for at least 10 ms before resetting it
+  ret = linuxspi_reset_mcu(pgm, false);
+  if(ret)
+    goto close_out;
+  usleep(10000);
+
   ret = linuxspi_reset_mcu(pgm, true);
   if(ret)
     goto close_out;

As to the warning message. I suspect somehow src/avrdude.conf.in was installed directly on your system as avrdude.conf. Our install makefiles take the .in file, replace the @AVRDUDE_FULL_VERSION@ and other @something@ variables with relevant strings and put the resulting file into the right place as avrdude.conf (no .in). So, maybe try to install the current version as documented in the wiki?

[PeterHouseJr]

I will test this in a few days and let you know.

After this fix, I should be able to use the default configuration file which should remove the issue.

[stefanrueger]

Any luck with testing this @PeterHouseJr?

[PeterHouseJr]

It is on my short list and should happen next week, after the holidays here. Peter House (904) 725-2103

…

________________________________ From: Stefan Rueger ***@***.***> Sent: Monday, November 25, 2024 7:35:02 AM To: avrdudes/avrdude ***@***.***> Cc: Peter House ***@***.***>; Mention ***@***.***> Subject: Re: [avrdudes/avrdude] v8 linuxspi won't connect - Reset Line Inverted ??? (Issue #1929) Any luck with testing this @PeterHouseJr<https://github.com/PeterHouseJr>? — Reply to this email directly, view it on GitHub<#1929 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AP7H3JRBP5LP455Z4ABAGC32CMKPNAVCNFSM6AAAAABQT22BY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJXHEYDEMRZG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[PeterHouseJr]

Stephan,

The linuxspi.c file I just cloned is slightly different than the diff output shown above. Please let me know if this is correct.

I am only roughly familiar with your diff output and am unsure if I am editing the file correctly.

I used this command to get the files this morning:
git clone https://github.com/avrdudes/avrdude.git avrdude8

I don't see these lines I expect beginning at line 244 in avrdude8/src/linuxspi.c :

static int linuxspi_open(PROGRAMMER *pgm, const char *pt) {
     goto close_gpiochip;
   }

And instead I see this (beginning at line 241):

  if(ret == -1) {
    ret = -errno;
    pmsg_ext_error("unable to get GPIO line %d. %s\n", pgm->pinno[PIN_AVR_RESET] & PIN_MASK, strerror(errno));
    goto close_gpiochip;
  }

Here is the change as I believe it should be (beginning at line 241):

  if(ret == -1) {
    ret = -errno;
    pmsg_ext_error("unable to get GPIO line %d. %s\n", pgm->pinno[PIN_AVR_RESET] & PIN_MASK, strerror(errno));
    goto close_gpiochip;
  }

  // Ensure the part is active for at least 10 ms before resetting it
  ret = linuxspi_reset_mcu(pgm, false);
  if(ret)
    goto close_out;
  usleep(10000);
    
  ret = linuxspi_reset_mcu(pgm, true);
  if(ret)
    goto close_out;

[PeterHouseJr]

Results of Modification testing:
Modified v8, Python Wrapper Not Controlling Rst before call to AVRDUDE:

Modified v8, Python Wrapper Holding Reset Inactive while AVRDUDE is launched:

Looking at this, the reset line is active for about 160,000us so I experimented with the timing in the AVRDUDE code with 5,000us granularity and came up with 80,000 does not work, and 85,000us does work as shown below.

This worked Modified v8 withactive time set to 85,000us:

I am choosing to use 100,000us since 85,000us may be marginal and 15ms should not make a difference at program time. Maybe this time should be specified in the .conf?

The Microchip/Atmel ISP application note 910 only mentions the Reset line should be controlled by the programmer. I am sure there is other documentation on this where the timing is specified. I have been unable to put my hands on it. I you have it or can find it, I would sure like a copy. I also sent a request to my MicroChip representative for this information and would be happy to share once I get it.

[stefanrueger]

Thanks for testing!

Great to know that if we change the 10 ms in the new code to 100 ms then it works for your setup. The only thing remaining is to to understand why. I would really like to understand this. Please read on

The suggested change was inspired by your hypothesis that I understood to be: If the part is held in reset before avrdude starts, any twiddling on SCK before avrdude starts will already start an SPI communication from which the true intended communication later on cannot recover. This was confirmed by your observation that if only reset is set up to be inactive (the, clamped to Vcc) before avrdude starts then all works fine. This is a great hypothesis. And one that convinced me that avrdude must change to ensure there is a proper reset edge from Vcc (inactive) to Gnd (active). Setting reset to GND (active) is not sufficient.

So, the first intervention is

  ret = linuxspi_reset_mcu(pgm, false);

I understand this to set reset to inactive, ie clamp target reset to Vcc, to allow the part to come out of reset should it have been setup in reset beforehand. The comment above that line mentions the part is active (meaning reset is inactive).

Now it really puzzles me that it makes a difference that the reset edge from Vcc to Gnd that avrdude issues needs to come some 85 ms afterwards. Why is 10 ms not enough? I have two hypotheses:

1. I vaguely remember that SCK needs to be at a certain level (GND?) when reset is issued. If so, avrdude might need to ensure this is the case, too.

2. If the board is at Vcc > 5.4 V and there is a cap on the reset line and there is no external clamp diode on reset to Vcc, then plucking the reset line in a certain way can create a 2·Vcc spike (so around 11 V) and the part enters into High-Voltage programming mode, which is the wrong kind of reset. Any of the hardware modifications (ensure Vcc < 5.4 V, remove the cap, add a clamp diode) removes that effect. See this discussion or this one

@PeterHouseJr You will know from your hardware setup which one is more likely. Please could you investigate as to which one of the two or figure out otherwise why the 100 ms wait should be necessary.

I really want to get to the bottom of this!

BTW

And instead I see this (beginning at line 241):

Yes, this is how it should be. Have you tried git diff after making changes? This should give you the same output as the one I posted above. The following line in the git diff output

@@ -244,6 +244,12 @@ static int linuxspi_open(PROGRAMMER *pgm, const char *pt) {

tells us that the code below that @@ line is at line 244 but the @@ line also conveniently tells us that the changes will be somewhere in the function linuxspi_open(). This does not expect the function itself to start at line 244.

Anyway, you did the right thing with the right code.

[PeterHouseJr]

@stefanrueger,

I do not see any evidence of a spike on the reset line which could put the part into high voltage programming mode.

From what I can see, MOSI data is clocked into the 328PB on the rising edge. Any rising edge on SCLK after the RST line goes inactive (GND) will clock a bit into the 328PB which, if not an intended clock, will lead to corruption which is unrecoverable without another RST inactive > 85ms.

This is also the reason AVRDUDE cannot recover with it's current retries as they are only 25ms apart and the reset line is NOT inactive for the required 85ms. If these retries were spaced at 101ms with 100ms of RST inactive then I am sure the retries would work. If this timing is not correct, there is no need for the retries. The chip entering the reset state happens much faster than 1ms.

I do not know why the 85ms of inactive RST is necessary and I am not sure the ISP documentation will tell us why - it will likely only tell us it must be > 85ms or so.

I would speculate the part must come up and have a stable clock before it can be programmed but I do not believe that takes that long. Maybe there is an internal timer of some type in case there is a slow startup high speed external clock of some type or maybe even a really slow external clock like a 32,768 Hz timekeeping crystal for very low power operation. Just guessing here.

Maybe some of these timings should be in the .conf so they can be adapted for different parts as necessary. I say this with no understanding of how difficult a task this may be.

Let me know if there is anything else I can test.

[stefanrueger]

current retries as they are only 25ms apart and the reset line is NOT inactive for the required 85ms

The documentation only requires a positive reset pulse of 2 clock cycles (only 61 µs at a vvv slow 32,768 Hz clock). So the tested intervention of setting reset Vcc for 10 ms should be more than plenty by 2 orders of magnitude. 100 µs should have been sufficient. I still don'e see where the 85 ms comes from.

The only thing I can think of is that SCK was not GND before that pulse. Could you please test with SCK being prepared to be pulled GND by your python app before avrdude is called?

Any rising edge on SCLK after the RST line goes inactive (GND) will clock a bit into the 328PB

agreed except ... goes active (GND) : reset is low-active

not see any evidence of a spike on the reset line

Just to be super sure: Please, could you measure Vcc and tell us. And confirm whether or not there is a cap between the reset pin of the ATmega328PB and the line that's driven by the host that avrdude sits on (what is the resistance between these two points?).

[PeterHouseJr]

The datasheet does say "a positive pulse of at least two CPU clock cycles" and in the very next step counters with "Wait for at least 20ms and enable serial programming by sending the Programming Enable serial instruction to pin MOSI". "At Least" signals me it could be more and the writer was not very sure.

Using the Internal oscillator here is a chart showing the possible worst case startup times. Maybe the 328PB has to get up and running before the RST line is taken active for programming. The default (I am using Brand New Parts with default fuse settings) is a little over 65ms (as per Note 2).

There are two things we are talking about. One is the part coming out of Reset when the RST pin transitions to 5v. The other is getting into program mode when the RST pin transitions to 0v. In this very limited testing it looks to me like the part has to power up, come completely out of Reset, and only then put back into reset to begin programming. As it is, we are NOT waiting the 20ms after going into reset before we enable serial programming by sending the Program Enable instruction - my measurements show this to be only 300us or so - and this works obviating the need to wait for 20ms.

Here is a picture of the Power using an Analog input on my scope:

Here is the same acquisition zoomed in to show the power rise time:

This is a pretty average rise time for a power supply at just under 200us (typically measured from 10%-90%). Additionally, we have a long time after Python turns on the power until AVRDUDE is launched and starts to control the signals.

I have probed the SCLK, MOSI, and MISO signals the same way and there are no glitches or spikes I can see. SCLK is at 0v before power on and stays there until AVRDUDE changes it. Same with MOSI and MISO only they are held at 5v.

My target board uses the internal pullup on the RST line and does not have any external Reset circuitry other than the connection to the programming header.

I understand the need to know why with much more detail. If you have additional things you would like me to check, I will do my best to help you.

[stefanrueger]

Thanks for your info. Yes, you make a few good points. I prefer an implementation that is close to the data sheet. No problem adding safety margins. Given what you say, the following diff should be closer to the data sheet:

diff --git a/src/linuxspi.c b/src/linuxspi.c
index 48573679..41102315 100644
--- a/src/linuxspi.c
+++ b/src/linuxspi.c
@@ -244,9 +244,16 @@ static int linuxspi_open(PROGRAMMER *pgm, const char *pt) {
     goto close_gpiochip;
   }
 
+  // Ensure a positive reset pulse of at least 2 clock cycles (use 1 ms)
+  ret = linuxspi_reset_mcu(pgm, false);
+  if(ret)
+    goto close_out;
+  usleep(1000);
+
   ret = linuxspi_reset_mcu(pgm, true);
   if(ret)
     goto close_out;
+  usleep(20000);
 
   if(pgm->baudrate != 0) {
     pmsg_warning("obsolete use of -b <clock> option for bit clock; use -B <clock>\n");

Main difference is the additional wait of 20 ms after going into reset, which is needed according to the data sheet.

If that doesn't work, perhaps play with both usleep() durations. Also of interest would be to play with the usleep() durations here; they conform to the DS, but happy to add safety margin so it works in practice.

avrdude/src/linuxspi.c

Lines 354 to 359 in 69c3293

	if(linuxspi_reset_mcu(pgm, false))
	return -1;
	usleep(5);
	if(linuxspi_reset_mcu(pgm, true))
	return -1;
	usleep(20000);

[PeterHouseJr]

Working to the data sheet is a very good strategy.

I will try your code tomorrow and adjust if/as necessary.

[PeterHouseJr]

For the record.

Here is the beginning of my conversation with the Florida Microchip technical representative, Bill Hawkins.

Now waiting for a response.

Recent Email from Bill

Bill,

Here is the foundation of the issue I am experiencing:

The hardware used is a Raspberry Pi 4 with a Sparkfun Pi AVR Programming Hat connected to a 328PM uC and the relevant pins on the uC are ONLY used for programming and are not connected to any other circuitry with the exception of the power supply. The power supply for this uC is 5v. The Hat has been slightly modified to provide 5v power to the target on command.

I have been using this setup for 7 years or so and have three sets of hardware. Recently, I took one set and updated the OS and the latest version 8.0 of AVRDUDE programming software. The software is called from a custom Python program I wrote. I do have a small subset of test software to provide the minimal functionality of a simple read of the Device Signature.

Unfortunately, AVRDUDE 8.0 would not connect to the uC (328PB). After a lot of debugging and communication with Stefan Rueger , on the AVRDUDE dev team, I was able to get it working by manipulating the RstST signal to be a logic 1 after power is applied and before AVRDUDE is called.

After modification of AVRDUDE to put the Reset signal high for 10ms before communication, it still did not work. It was finally determined that the Reset line had to be High for 85ms before communication. 80ms would not work.

Here is a Scope shot showing the python program setting the Reset line high before calling AVRDUDE and Good Communication:

Here is a scope shot showing the Reset line held high by AVRDUDE for 10ms and failed communication:

Here is a scope shot showing the Reset Line held high by AVRDUDE for 85ms and good communication.

Here are the section of he datasheet which refer to Serial Programming.

We would like more information regarding serial programming in order to more fully understand the process and to make AVRDUDE more robust. I recall seeing an Atmel document describing this programming process for the entire Atmega family and an unable to find it at this time. The only documents I have now are the 328PB datasheet, and the Application Note 910, neither of which address this issue or have specific signal timing information for this process.

Any assistance on this would be appreciated and used to make AVRDUDE a better product.

Thank you so much,

Peter House
(904) 725-2103 Please Leave a Message if No Answer

PS - Here is a link to the AVRDUDE github discussion on this topic: v8 linuxspi won't connect - Reset Line Inverted ??? · Issue #1929 · avrdudes/avrdude

---

Reply Email from Bill

Hi Peter:

AN910 is all that I have on the programming… If you need more specific information, let me know exactly what you need and I can ask the factory experts.

Best Regards,

Bill Hawkins
FAE, Florida
Microchip Technology
407-252-3662

---

First Email To Bill on this topic

Bill,

I am now using vscode/WinAVR for my Atmel programming and have no real need for the MPLABX IDE at this time.

I am also using Raspberry Pi with AVRDUDE for programming for development and for production. The new version of AVRDUDE has a couple of issues programming the 328PB and I am helping the developers with some testing and refinement and am looking for the ISP specification for the 328PB. I already have the 910 application note, but I need more precise timing information.

Is there an ISP specification document available?

Thank you,

Peter House
(904) 725-2103

[PeterHouseJr]

@Stefan,

After further testing there is nothing new to report. It looks like >85ms is still the minimal time Reset should be in the inactive (True or 1) state before communication begins with the part.

Here is the curious thing:

Notice the Reset line is held high for about 175ms between the time the Reset line is setup by the Python program which then shells out to AVRDUDE. The 175ms is a result of how long it takes AVRDUDE to load and begin execution and can vary by +/-25ms. AVRDUDE immediately takes the Reset line Low (Active) for roughly 1ms and then high again for 10ms before beginning communication which is successfull. Various combinations of this pattern were attempted with code inside AVRDUDE and in any case, the reset line had to be inactive (high) for a most of 85ms before communications were successfull.

Hopefully we can get some help from Microchip to further understand what is going on with the Serial Program Load functionality.

[stefanrueger]

Thanks @PeterHouseJr: The scope images don't look like AVRDUDE sleeps for 20 ms after pulsing reset high. That was the bit of the datasheet that my initial change didn't implement. The second version has an usleep(20000); in the suggested code

[PeterHouseJr]

This may be is a mistake in the datasheet. Ity certainly should not hurt to have the 20ms delay in the AVRDUDE codebase.

As the programming engine has evolved over the years and capabilities like DebugWire have been added, it is hard to tell what particular timings might be necessary for any given part.

My memory is that there is a document regarding the specific timings of the Serial Programming engine.

I hope my technical contact at Microchip can get us some more detailed information.

[stefanrueger]

should not hurt to have the 20ms delay in the AVRDUDE codebase

But have you tried that? Didn't see that in the scope images. In absence of better info I'd go with what's available.

[PeterHouseJr]

Tried and made no difference along with a lot of other things. The 20ms delay certainly did not hurt.