Feature hvsp ppi #1445

psagi · 2023-06-26T14:24:14Z

With this patch and a simple dapa-like hardware avrdude is able to re-enable the RESET function of PB5 of ATtiny85 on the Digispark board. To be more accurate: signature reading, fuses reading and writing in HVSP (High-Voltage Serial Programming) mode is implemented. Tested on ATtiny85 on a Digispark clone board. (Should work for other AVRs supporting HVSP.)

…er is enabled

… in HVSP mode

…hecking SDO when latching

mcuee · 2023-06-26T14:48:38Z

I actually do not know what is dapa-like just reading the above message. But then it is mentioned in the configure file.

#------------------------------------------------------------
# dapa_hvsp
#------------------------------------------------------------

programmer
    id                     = "dapa_hvsp";
    desc                   = "Direct AVR Parallel Access cable for HVSP mode";
    type                   = "par";
    prog_modes             = PM_HVSP;
    reset                  = 16;	/* RESET (0V) on HIGH and 12V on LOW */
    sck                    = 1;	/* SCI in HVSP */
    sdo                    = 2;	/* SDI in HVSP */
    sii                    = 3;
    sdi                    = 11;	/* SDO in HVSP */
;

mcuee · 2023-06-26T14:50:01Z

I can not test this though as I do not have access to a PC with parallel port.

And this will not work under Windows or macOS. Probably it will work on Linux and FreeBSD if one has the right PCs with real parallel port.

mcuee · 2023-06-26T14:52:07Z

From github action, this PR does not build under Windows.

stefanrueger · 2023-06-27T18:53:36Z

Thanks for your PR @psagi . This would be the first bit-banging high-voltage serial programmer other that the official ones. Good!

Avrdude knows 3 programmers and 23 parts that support HVSP programming:

$ avrdude -c*/At | grep PM_HVSP
.prog	stk500hvsp	prog_modes	PM_HVSP
.prog	stk600hvsp	prog_modes	PM_HVSP
.prog	dragon_hvsp	prog_modes	PM_HVSP

$ avrdude -p*/At | grep PM_HVSP | wc
23

The PR needs a few changes before it can be considered for merging:

The scope of the PR is relatively modest: one part (t85), parallel PC interface, HVSP programming of some but not all memories of the t85: signature, fuses, just enough to change fuse settings after bricking the device (provided the circuit of the project allows access to the needed I/O pins). Rather than being a special-purpose recovery programmer, it would be far better if the programmer was to implement access to all available memories and if it was to consider all 23 HVSP parts. The latter should be easy as you say yourself, but it should be done. Type avrdude -p*/At | grep PM_HVSP for the list of parts. I predict the project will get requests for expansion (more memories, more parts, more programmer types), and I for one prefer a PR that does not invite these types of issues.
The implementation of the programmer does not follow the usual programmer implementation where code for the programmer fills in all the low-level access functions such as erase_chip(), read_byte(), paged_load() etc; instead it follows the way the TPI interface is implemented through enhancing the general avr_read_byte(), avr_write_byte() etc functions. I for one am at sixes and sevens over this and would like to hear from other maintainers what they think. There are pros and cons to this approach. Major disadvantages as I see them are
- Reviewing is so much harder when the new code for the programmer potentially affects virtually everything else, at least those programmers that use the standard avr_...() calls
- It looks decidedly hacky to change central avrdude functions for a modest scope expansion
  I would prefer a PR that follows the way of how pp and hvsp programmers are dealt with in stk500v2.c.
The PR introduces commands for HVSP akin to ISP commands. It's the same syntax (good), but at the cost of artificially introducing nop commands to have 4-byte commands (bad). I wonder if the external representation in avrdude.conf is necessary: when the project introduced a description for ISP commands there were already different commands for different parts and the whole ISP interface was very much in flux, new parts were coming along, so a language to describe the commands was welcome and indeed necessary. I am not convinced the same necessity applies in 2023 for HVSP; almost certainly there will be no more new parts that have a HVSP interface, and the existing HVSP interface seems to be the same for all parts (with the possible exception that some HVSP parts might write flash byte-wise not page-wise). So I would argue these HVSP commands don't need that prominent a place in avrdude.conf. They can simply be #define constants once it's verified they are the same over the ten data sheets that cover the 23 HVSP parts:
If the new memory command properties (read|write)_hvsp_(cmd|data) were introduced they would need thoroughly documenting and they would need to be treated in developer_opts.c so that avrdude -p*/s prints them. A lot of work for little benefit.
And the PR needs to be portable, I am afraid, so it works across platforms

mcuee · 2023-06-27T23:06:45Z

And the PR needs to be portable, I am afraid, so it works across platforms

@stefanrueger
As of now, Parallel Port based programmers will not work under Windows (Vista/7/8/8.1/10/11) due to the lack of suitable driver.

Please refer to the following PR. The old giveio.sys may work on Windows XP which we do not support any more.

Remove 'windows' folder with giveio.sys driver #769

I also believe that it will not work under macOS either.

I 8000 have collected some info here.

Known issues of avrdude #1444 (comment)

psagi · 2023-07-01T08:47:11Z

@stefanrueger Big thx for the detailed review and discussion of my PR! Let me share my view on the issues that I have also considered during implementing the indeed minimal fuse-resetter feature.

You are totally right wrt. supporting every memory type of this AVR family. It is mostly the lack of time that prevented me from doing that. (Being this fuse-resetter a side project of another, more complex one that I am doing using the Digispark board.) It is fairly possible that I move on w/ implementing the support for other memories, once I have a bit of spare time. (Or some other contributor might find interesting to do this.) Another thing that should be taken into account when considering the usefulness of this enhancement is that once the reset pin or other fuse settings that prevent accessing the MCU in SPI mode are fixed, there is really no need to use HVSP. And SPI is fully and perfectly supported for this AVR family by avrdude (even with the simplest programming adaptors - like DAPA). To complete the 'unbrick' feature of avredude, Chip Erase command must be implemented, however. (Which should not be a problem.)
Wrt. supporting all HVSP-capable parts I totally agree. What prevented me from enabling the feature for the whole family in avrdude.conf.in is that I have access only to the ATtiny85 AVR and I would not release a feature that is untested. However I am happy to refactor avrdude.conf.in a bit so the common features of this AVR family go into a parent part entry and then every HVSP-capable AVR can inherit this feature. This would then require extensive regression testing which I would definitely need help from contributors having access to the rest of the HVSP-capable AVR family.
I also fully agree with the concerns about the TPI-like hacking the HVSP mode into the generic SPI code. My decision was based on two considerations:
i. It looked less work as a lot of code parts are re-used.
ii. The bitbang code has no plugin-like support for implementing different programming protocols. So either it would had to be done (lots of refactoring) or a significant amount of code would have been copied (resulting in a less maintainable code - but reducing the amount of possible regression indeed).
At the time of writing I am still unsure how the "programming protocol" concept should have been nicely and cleanly implemented in avrdude. (This must have been the dilemma with the TPI support too.)
Just a side-note: I also tried to figure out how the cryptic hvsp_controlstack works and if I can reuse it in any way for a bitbanging programmer, but found no sufficient public information about that on the Internet. (Sure, I did not get into reverse-engineering the programmers using this feature.)
The reason for putting the HVSP commands into avrdude.conf is that that way I could easily re-use all the generic functions of the bitbang code managing the instruction, data, address and output bits. There must be an easy way for reusing this functionality without putting these commands through the config file parsing code, but it did not seem trivial to me at the time of investigation. I totally agree that these HVSP commands have no room in avrdude.conf since there is a little chance that it is useful to change them without touching the avrdude source code.
I am going to look into developer_opts.c. Telling the truth I have not been able to figure out yet what this piece of code does. Of course it is not a problem to add the new elements to the description section of avrdude.conf.in. (I have forgot it in fact. Thanks for noting.)
I will definitely look into the build logs for the Windows platforms. I see no reason why this enhancement can not be portable, so I must be able to fix it easily. (I have no access to a Windows-based build environment, so I will rely on the CI chain of the Github repo to test this.)

To sum it up, my plans are (for short term):
I. Implement Chip Erase and test it with ATtiny85.
II. Look into the ways of removing the HVSP commands from the config file (but still using the existing command bit handling code).
III. Look into developer_opts.c and the functions that I should add.
IV. Add description of new avrdude.conf elements.
V. Fix the Windows build.

I am happy to hear your further thoughts on this, and especially the nice way of separating the HVSP functionality from the generic avr code but re-using the command bit handling and bitbangig parts.

psagi · 2023-07-01T08:51:50Z

I actually do not know what is dapa-like just reading the above message. But then it is mentioned in the configure file.

Sorry for being cryptic. It is a very simple circuit that fits in the case of a DB25 ('printer') connector. Details on this: https://pety.dynu.net/dapa_hvsp/
(The link is also included in avrdude.conf.in.)

#------------------------------------------------------------
# dapa_hvsp
#------------------------------------------------------------

programmer
    id                     = "dapa_hvsp";
    desc                   = "Direct AVR Parallel Access cable for HVSP mode";
    type                   = "par";
    prog_modes             = PM_HVSP;
    reset                  = 16;	/* RESET (0V) on HIGH and 12V on LOW */
    sck                    = 1;	/* SCI in HVSP */
    sdo                    = 2;	/* SDI in HVSP */
    sii                    = 3;
    sdi                    = 11;	/* SDO in HVSP */
;

stefanrueger · 2023-07-01T13:49:31Z

@psagi Can I suggest looking at how @jkent implemented an ftdi bitbanging jtag programmer for PR #1324. This is very well written, follows the AVRDUDE philosophy of separating out programmers, uses compile-time constants for the JTAG commands and works for a variety of JTAG parts and virtually all memories. The only reason we haven't merged PR #1324 yet is that we first need to establish exactly which parts it works for, but the team is on the case.

easy way for reusing this functionality without putting these commands through the config file

You can or the address into the constant command bits just like Jeff's code does. You would have different bitbang functions, of course, but the principle is the same.

some other contributor might find interesting to do this

In my experience this is very unlikely: even 10-year old computers rarely have parallel ports, so I predict the number of people being interested in this is vvv small. Incomplete PRs more likely raise expectations and lead to complaints that then clutter the issues page b/c no-one comes forward solving what the original contributor failed to provide, which isn't helpful for the maintainers and the user base alike.

there is really no need to use HVSP [other than unbricking fuses]

Any implemented programmer should be a full programmer not only one that is able to reset fuses. This to ease documentation and maintainability and to avoid raising unmet expectations. It's not that hard to serve all memories, see code example here and here.

going to look into developer_opts.c

Not necessary if you follow above route.

Windows platforms

@mcuee told us there are no drivers for parallel ports in Windows (Vista/7/8/8.1/10/11). So you might need to restrict your code using #if HAVE_PARPORT.

PR #1324's approach works so much better for the AVRDUDE philosophy, maintenance that I suggest closing this PR #1445 altogether, and asking you to consider the way PR #1324 has contributed a programmer if you wanted to provide a useful HVSP programmer for AVRDUDE.

stefanrueger · 2023-07-01T14:43:38Z

happy to hear [about a] way of separating the HVSP functionality from the generic avr code

Please do consider above (use the same techniques as PR #1324). Another pro-tip: start form scratch from the current main branch to avoid merge conflicts. Your branch is > 417 commits behind.

psagi · 2023-07-01T16:13:09Z

@stefanrueger Thank you for the insight and your time reviewing this PR. I have looked into PR #1324 and understood that going that way would be a huge benefit wrt. avrdude code maintainability - and also a quite significant effort to refactor my PPI HVSP code. Considering PPI is really not in the wild these days, this feature might be interesting only for the ones like me having piles of ancient hardware in their garage :)
I decided to leave it as a public fork on Github - if anyone might be interested.

stefanrueger · 2023-07-01T18:05:46Z

Fair enough, .. and should you stretch to implementing a full HVSP bitbanging programmer I am sure the team here would welcome a new PR very much. ... and thanks for thinking of us in the first place

mcuee · 2023-07-02T05:21:54Z

Hmm, I can not move this to discussion, never mind.

psagi added 30 commits April 2, 2023 21:00

dapa_hvsp added to config

ca06d03

show SII pin when in HVSP is supported

12cb796

invert the RESET pin for dapa_hvsp, so it drives 0V to MCU when adapt…

8870346

…er is enabled

latch to HVSP mode implemented

0b341b4

fix: operator precedence in bitbang_initialize()

9015eab

debug bitbang_initialize_hvsp()

0899f9b

number of retries for HVSP latching increased

4ef9466

signature reading in HVSP mode added to config

847808f

fix: signature read HVSP data format for ATtiny85

291145e

signature reading in HVSP mode

9e0c037

debug bitbang_txrx_hvsp() pin reading

223f259

debug written and read HVSP bits

11d78e4

fix: debug HVSP pins

ad70b2a

New dapa_hvsp hardware, SCI is inverted.

1a01b6a

Fix: read data waw shifted 1bit right.

94941eb

FIX: properly initialize SCI in HVSP mode

2793be0

Fuse read commands added for HVSP mode

f1cd8e7

FIX: include higher bits of efuse in the result when reading ATTiny85…

626e466

… in HVSP mode

Write fuse commands implemented for ATTiny85 HVSP

499d980

vcc_detect pin added to avrdude.conf

fa43ce5

FIX: vcc_detect pin handling in pgm_fill_old_pins()

136efa2

PPI: VCC_DETECT pin handling when HVSP is supported

563afde

VCC detection in HVSP latching

d446c39

dapa_hvsp: prevent VCC leaking from PPI to MCU, adjust delay before c…

2d723f7

…hecking SDO when latching

dapa_hvsp: revert to simple driving of SCI

9664b1f

FIX: clock polarity (dapa_hvsp)

6992452

HVSP: wait for AVR ready instead of static delay when latching

78628ed

FIX: bitbang_wait_for_signal_hvsp(): timeout calculation

fbcaad9

dapa_hvsp documentation link added

0c4b6c5

Revert to default build options.

7b8ea37

mcuee added the enhancement New feature or request label Jun 26, 2023

Description for HVSP commands added.

30c0437

term.c is used by libavrdude

205d06d

fix merge conflict of src/CMakeLists.txt

d862c82

psagi closed this Jul 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Feature hvsp ppi #1445

Feature hvsp ppi #1445

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Feature hvsp ppi #1445

Feature hvsp ppi #1445

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!