Feature request: perform erase before flashing

[T3sl4co1l]

Hello,

This tool happily corrupts device data. Namely, a Flash write cycle is just that, write only. I understand this from a point of expressiveness, and that's fine for library purposes. For practical purposes, you're always erasing beforehand. When using from CLI, I have to manually run an erase cycle first, or put two commands into a batch/script, to actually reprogram a device.

Erase should simply be another option.

Inconsistency: it seems fuses NEVER need to be erased. (I don't know offhand if that's a quirk of UPDI or what.)

[xedbg]

Hi Tim, you are not the first to request this :) and yes, we all agree its annoying. After using it for a few years, doing the separate pre-erase becomes a (bad) habit.
All memory types are not equal and hex files can contain a mix of them, so we have chosen to ignore this until we settle on the best way to do this (yes, we have discussed it a lot...) that keeps all architectures happy. Correct, fuses to not need an erase (they are like eeprom) which is just how they are. To implement auto pre-erase correctly, I suspect we should be erasing any memory sections which are included in the (hex) file being programmed, if that area requires erasing, or if the specified area (-m) requires it. Not all flash architectures and debuggers support the same 'region erase' capabilities... so the temptation is just to do a chip erase... but that may have undesirable side effects, like erasing eeprom while writing flash. Logged (again) internally as DSG-3951, although fixing this will have to be argued through with a fair amount of coffee again... Thanks for the input!

[T3sl4co1l]

Huh, I always assumed HEX was flat. But that makes sense. Ah, I see just objcopying an ELF puts the Flash at zero and fuses at, 0x820000 I think that would be. Which sounds like where they're represented in the ELF too.

Which, that'd be another thing, take in the ELF format directly. That's probably a lot more work and not really needed with the ready availability of binutils... just nice to have eventually.

As for erase, there's a fuse about EEPROM erase, at least on this device; I would tend to just assume the user's set that correctly, or maybe add a confirm prompt/option; or maybe read the fuse and check if that was intended or whatever. Or, I mean... how does avrdude handle it? :P

[sh-mcu8apps]

You are right about the EEPROM fuse for AVRs, but remember this tool is also for PIC devices. Some PIC devices have bulk erases that only erase Flash and some don't. Then if you have a hex file with several segments, do you erase the whole flash or just the segments to be written (remember you can have several segments in a hex file for the same memory). What if the device has erase sections that does not match the segments in the hex file. Then the tool would have to read out flash, modify according to hex content and write back. All in all what you suggest is possible but far from trivial. And it might also increase programming time significantly. But I do agree, having to explicitly run erase upfront is annoying.

[xedbg]

"lowest cost" solution proposal might be: add --erase switch (or something like that) which will do the easiest/simplest chip-erase before writing whatever its writing, from wherever its writing from. This is back-compatible with existing behaviour, and is explicit enough to not have to do anything complicated (you ask for it, you get it). Cost to users is a new (bad) habit of adding the --erase, but at least it becomes a one-liner. Might also be an option to add a "hint" to users (logging.warning) if verification happens to fail and --erase was not specified.

[xedbg]

This didn't make the cut for 3.10.2 and will be scoped for 'next' release

[xedbg]

@T3sl4co1l : Version 3.11 on pypi test has --erase switch on write: https://test.pypi.org/project/pymcuprog/3.11.3.142/

as documented, and as suggested here, this is the "lowest-cost" solution in terms of simplicity and back-compatibility. --erase will do a chip erase before writing from an Intel hex file It will not work for writing bin or literal (excluded to avoid complications)

[domdfcoding]

What's the timeline for releasing 3.11 to PyPI proper?

[xedbg]

Hi Dominic, It has unfortunately been slipping out of the last few sprints, but we still hope to release it this side of summer. Which means May/June.
(There should be few risks attached, but we need to run a set of QA procedures.) Its good that you ping us like this - then we are aware of you! (Edit; currently scheduled for sprint 16.05-27.05) (Edit2: I just published the latest build of (3.13) to test.pypi to help to fast-track any pre-release verification)

[xedbg]

--erase is now supported in 3.13