bugAVR Downloader/UploaDEr - Bugs: bug #60008, linuxspi programmer does not seem...

 
 

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

bug #60008: linuxspi programmer does not seem to release AVR reset when finished

Submitter:  None
Submitted:  Thu 04 Feb 2021 10:27:28 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  Ralf Herrmann
Originator Email:  -email is unavailable- Open/Closed:  Closed
Release:  SVN snapshot Programmer hardware:  ARMv7 embededed computer
Device type:  ATmega328pb

Jump to the original submission

Fri 03 Dec 2021 10:35:18 PM UTC, comment #6: 

Patch #1506 is supposed to fix whatever can be fixed.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 01 Dec 2021 09:38:13 AM UTC, comment #5: 
Alex Sverdlin <sverdlin>
Wed 01 Dec 2021 09:34:10 AM UTC, comment #4: 

Ignoring GPIO APIv2 ;)

But I can publish -E patch if you think it makes sense.

Alex Sverdlin <sverdlin>
Wed 01 Dec 2021 09:20:39 AM UTC, comment #3: 

That's a bit odd though.

If I use

gpioset 0 25=1

the non-reset state persists even after gpioset terminates. What are they doing different then?

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 01 Dec 2021 09:17:25 AM UTC, comment #2: 

Well, I've implemented "-E reset"/"-E noreset" support for linuxspi programmer, only to understand that Linux GPIO API v2 doesn't allow one to configure persistent GPIO state beyond application lifetime.

Either the API shall be extended, or, another application shall be developed for the mentioned use case, which does nothing else than just hog the GPIO line in the proper state as long as one communicates with the AVR. And now that I'm thinking about it, what happens after programming is probably not avrdude responsibility anyway.

Alex Sverdlin <sverdlin>
Sun 28 Nov 2021 10:35:14 PM UTC, comment #1: 

I observed the same behaviour.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 04 Feb 2021 10:27:28 PM UTC, original submission:  

Dear avrdude team,

first of all thanks for your nice work!

I'm currently working on an embedded platform based
on an ARMv7 embedded CPU and Linux (Debian Buster).
The board has an AVR ATmega328pb attached to the A7
via SPI (AVR is slave) and the A7 also has one of its
GPIOs connected to nRST of the AVR.

Yesterday I fetched r1450 from svn, build it, and tested
communication with the AVR. I'm using programmer linuxspi
(obviously) and specify reset pin via command line as per man page.
At first it went fine and avrdude let me upload my app to flash. Verification was successful.

However, after uploading the app, the AVR did not respond any
more to SPI commands i sent from the A7.
Long story short, i ended up checking the source code in
linuxspi.c and did not see any code that releases the reset
GPIO line of the AVR.

To test my suspicion i copied a few lines from linuxspi_open()
to linuxspi_close() and changed it so that nRST is released.
That did the trick for me, after upload to flash AVR immediately
reacts to SPI connection from A7.

I'm not 100% sure this is unintended behaviour, however,
i found a way older version of avrdude that has the
initial code for linuxspi programmer (i think based on 6.1).
This older code used the (now deprecated) sysfs-way to operate
the reset pin. It has indeed code to release the reset pin
through linuxspi_close() (it actually makes the GPIO an input
to the host CPU again thereby letting the pullup resistor do
the actual release).

I hope you fond this report useful.
If you need more detail, let me know.
Keep up the good work!

BR,

Ralf

Anonymous

 

(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 sverdlin (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-03 joerg_wunsch StatusConfirmed Fixed
        Assigned toNone joerg_wunsch
        Open/ClosedOpen Closed
    2021-11-28 joerg_wunsch StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code