Which programmer supports "-E reset"?

[Tropaion]

Hello,
I don't know where to ask/find it.
I have an application, where, when the programming an ATxmega32E5 is done, the reset signal should stay activated until said otherwise.
I have the programmers AVRISP MK2 and Atmel ICE and tried both.
With both it says "avrdude warning: -E option not supported by this programmer type", but I can't find anywhere, which programmers support this.
So, can someone tell which programmer I should use?

[stefanrueger]

Good question! Originally -E was implemented for parallel programmers (remember the parallel port for printers from the last millennium?). Only a couple of other programmers followed suit. Looking at the source code we have

$ grep "parseexitspecs *= *[^=]" -r src
src/pgm.c:  pgm->parseexitspecs = NULL;
src/par.c:  pgm->parseexitspecs = par_parseexitspecs;
src/linuxspi.c:    pgm->parseexitspecs = linuxspi_parseexitspecs;
src/flip2.c:  pgm->parseexitspecs   = flip2_parseexitspecs;

Maybe the hardware pros amongst the team can help out with alternative ways of doing what you want to achieve... @mcuee @MCUdude

[Tropaion]

remember the parallel port for printers from the last millennium?

I'm too young for that, but I think I know what you mean 😄 .
I currently have an working but not very nice solution. I keep an python thread running in the background which keeps avrdude open in terminal mode, but sometimes this creates some annoying issues.
This was also the reason I came upon the "-E" command while searching for alternatives.

[mcuee]

@MCUdude

I think you are more familar with Microchip tools like Atmel ICE. Maybe you can help to see if we can offer such an options for some of the programmers.

[mcuee]

@stefanrueger and @MCUdude

I think we can probably implement such an option for programmers which can toggle the reset pin at different state.

linuxgpio should be one candidate. @stefanrueger mentioned that linuxspi already has -E support.

We have some programmers which have similar functions, not using -E. I think serialupdi is one example.

• Added missing RTS/DTR management feature to serialupdi programmer #811

[MCUdude]

I'll look into what it would take to implement this for jtag3 programmers.

@dioannidis I don't know much about the USBasp firmware, but it is possible to leave the reset pin low after programming?

[Tropaion]

@MCUdude That would be really nice, especially for Microchip tools.
But I'm really surprised that this topic never came up if you consider how long avrdude exists.

[dioannidis]

@MCUdude

@dioannidis I don't know much about the USBasp firmware, but it is possible to leave the reset pin low after programming?

IIRC yes it's possible but let me check to confirm

[MCUdude]

I'll look into what it would take to implement this for jtag3 programmers.

I've been in contact with the Microchip developers who are in charge of the JTAG3/EDBG firmware. It's not possible to leave the reset pin low after a programming session, so there is not much we can do about this...

IIRC yes it's possible but let me check to confirm

@dioannidis thank you! The USBasp is the go-to programmer for lots and lots of people. If this was possible, the USBasp just became a little more useful!

[stefanrueger]

@MCUdude Were you volunteering to implement -E for usbasp? If not I'd close this issue.

[MCUdude]

@MCUdude Were you volunteering to implement -E for usbasp?

No, sorry. I don't know the USBasp firmware well enough to pull this off. @dioannidis perhaps?

[dioannidis]

@MCUdude, @stefanrueger

Oops, regarding reset pin low after programming, it fall between the cracks, sorry for that . But I confirm that USBasp can leave the reset pin low .

Regarding -E, I suppose that I need to read the #1844 , correct ?

[MCUdude]

@dioannidis yes, please have a look at #1844. You can just copy the way it's implemented for the flip2 programmer

[MCUdude]

@dioannidis A new release of Avrdude is about to happen in a few weeks, and it would be awesome if you managed to get it (-E reset / -E noreset) working before the release. Please let me know if there is anything I can do to help out. At least I can update the documentation in #1853 for you!

[dioannidis]

@stefanrueger, @MCUdude

I thought that this will remain open now that I'm working on it .

[MCUdude]

I thought that this will remain open now that I'm working on it .

I'll open a new issue just for this.

[stefanrueger]

I thought that this will remain open now that I'm working on it .

@dioannidis Ooops! That was an auto-close when merging a PR (this issue was linked to a PR and I hadn't realised it needed to be unlinked). @MCUdude Thanks for creating a new issue