bugAVR Downloader/UploaDEr - Bugs: bug #53839, ATtiny and Programmer running...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #53839: ATtiny and Programmer running after download done

Submitter:  John Barrington <johnbarr>
Submitted:  Fri 04 May 2018 10:03:18 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  None Originator Name:  John Barrington
Open/Closed:  Open Release:  6.3
Programmer hardware:  USBtinyISP & Genuino Device type:  ATtiny84

Sat 05 May 2018 06:34:31 AM UTC, comment #5: 

That reminds me:

Back in the days of parallel-port based programming dongles,
AVRDUDE had full control over all programming signal lines.

The way the /RESET (and potential power supply) lines were
left at program termination there is determined by the -E
option.

If USBtinyISP supports something like that, -E could be
implemented for this programmer as well.

Joerg Wunsch <joerg_wunsch>
Group administrator
Sat 05 May 2018 06:23:02 AM UTC, comment #4: 

I'm afraid this is not a feature of AVRDUDE but of USBtinyISP.

I could be mistaken on this, but before accepting it as an
AVRDUDE bug, I'd like to see it being reproduced with a
not-quite-so-cheap programmer like the AVRISPmkII.

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 04 May 2018 11:40:23 PM UTC, comment #3: 

There are still applications in which chips are programmed separately outside the devices in which they are eventually installed. After all, some AVR chips are still sold in DIPs to facilitate this.

However, even if you discount this case and even if you are O.K. with letting the newly programmed chip run immediately after programming it, there is still johnbarr's "bug #2" to consider.

For chips with a limited number of pins, i.e., the ATtiny84 and 85, the same pins used for programming the chips are often also used as I/O pins in the application.

We have noticed that if the code downloaded to the chip runs and outputs signals to either the MISO or MOSI pin, AVRDUDE apparently responds by generating signals on the SCK pin.

If the SCK pin is used as an input pin in the application, this can have undesirable effects.

In johnbarr's case, the SCK pin is also used as an input from a switch, and the SCK signals generated by AVRDUDE after the chip is programmed activate the switch input and cause his code to modify EEPROM.

In another application, the unwanted SCK signals could have a different undesirable effect.

It would be better if AVRDUDE didn't send any signals to a chip once it has been programmed.

Michael Sadaway <mjsadaway>
Fri 04 May 2018 10:37:55 PM UTC, comment #2: 

Was I clear? The programmer and the downloaded code should not communicate.

John Barrington <johnbarr>
Fri 04 May 2018 10:13:18 PM UTC, comment #1: 

I'm open for discussions about this, but for that, please
subscribe to the avrdude developers list, and start a
discussion there.

In my opinion, the current behaviour is what most people would
expect from AVRDUDE, rather than a bug.  Remember, this is
"ISP", or "In-system programming", so the main purpose is not
to program the controller in an external socket as it used to
be the case in the days of EPROMS, but rather to program the
device inside the target circuitry. From there, the usual goal
is the device starts operating after programming finished.

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 04 May 2018 10:03:18 PM UTC, original submission:  

We have analyzed the actions of our programmer, Avrdude / USBtinyISP, when and after downloading our HEX file to our ATtiny84. We find faulty behavior after download is complete.



Before Avrdude starts downloading, RESET (Attiny84 pin 4) is HIGH. While Avrdude is downloading code, it sets RESET to LOW. When Avrdude is finished downloading it sets RESET back to HIGH and, RESET being HIGH, our downloaded code starts running immediately while the chip is still in the programmer socket.



Using an alternative programmer, an Arduino Genuino running ArduinoISP.ino, we find the problem also exists. When we used the Genuino as a programmer running ArduinoISP instead of a USBtinyISP, ArduinoISP also set RESET back to HIGH.



Modifying ArduinoISP.ino (see code below) to continually write RESET LOW after downloading keeps our downloaded code from running and interrogating Pin 9, the programmer's SCK. This allows the Attiny84 and its code, when moved from the programmer socket to its destination and run uninterrupted by any pulses on Pin 9, to find the initial value in the first byte of EEPROM.

------------------------------------------------------------------

Bug #1: After Avrdude has finished downloading, RESET should be left LOW so that the ATtiny84 downloaded program will not run (until the ATtiny84 chip is removed from the programmer socket and placed in its final destination).

------------------------------------------------------------------



After the programmer has finished downloading our code to the ATtiny84, our code runs and writes output. The programmer reads this output and writes to the ATtiny84, to the programmer's SCK output. Our code recognized this spurious pin 9 input (a "switch input" to the code) and, in response, writes the first byte of the ATtiny84 EEPROM.



Both USBtinyISP and ArduinoISP continue running after setting RESET to HIGH. Thus both the programmer and the downloaded code in the ATtiny84 are RUNNING AT THE SAME TIME.

------------------------------------------------------------------

Bug #2: After the programmer, ArduinoISP or USBtinyISP, has finished downloading, it should loop doing nothing. It should not read from the ATtiny84 nor write to it.
------------------------------------------------------------------


We find:

1. The problem occurs with multiple versions of Avrdude.

2. The problem occurs with all of our USBtinyISPs.



---------------------------------------------------------------------------------



Part of Arduino ISP:



void end_pmode() {

SPI.end();

// We're about to take the target out of reset // WHY? so configure SPI pins as input

pinMode(PIN_MOSI, INPUT);

pinMode(PIN_SCK, INPUT);

reset_target(false);

pinMode(RESET, INPUT);

pmode = 0;

)

---------------------------------------------------------------------------------

The same part of Arduino ISP, modified to work:

void end_pmode() {

SPI.end();

// We're about to take the target out of reset so configure SPI pins as input

pinMode(PIN_MOSI, INPUT);

pinMode(PIN_SCK, INPUT);

reset_target(false);

pinMode(RESET, INPUT);

//

Keep RESET low:

digitalWrite(RESET, LOW);

// Keep continually setting RESET LOW

pmode = 0;

}

-----------------------------------------

John Barrington <johnbarr>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mjsadaway (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by johnbarr (Submitted the item)
  • -email is unavailable- added by johnbarr (Related to bug #53609.)
  • -email is unavailable- added by johnbarr (Related to bug #53609.)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-04 joerg_wunsch StatusNone Wont Fix
    2018-05-04 johnbarr Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code