adafruit / adafruit/Adafruit_CircuitPython_AVRprog
Flash-write repetitively missing bytes on 0x100-boundary
- Dominant language
- Python
- Stars
- 35
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Description
Writing Hex-file to ATmega644PA using below chip_dict, a Feather nRF52840 and a bit of wiring to the ISP target. Works beautifully and validates - but target code does not run as expected.
```
.
.
.
# Processor definition
atmega644pa = {'name': "ATmega644PA"}
atmega644pa['sig'] = [0x1E, 0x96, 0x0A]
atmega644pa['flash_size'] = 65536
atmega644pa['page_size'] = 256
atmega644pa['fuse_mask'] = (0xF7, 0x8F, 0xFD, 0xFF) # Low, High, Extended, Lockbits
.
.
print("Programming flash with",filename)
if not avrprog.program_file(atmega644pa, filename, verbose=False, verify=False):
error("Failure programming flash with" + filename )
else:
print("Programmed OK")
time.sleep(1)
print("Verifying flash against",filename)
if not avrprog.verify_file(atmega644pa,filename,verbose=False):
error("Failure verifying flash against " + filename )
else:
print("Validated OK")
```
creates this screen output
```
Working with an ATmega644PA CPU. Good!
Read lockbits: ['0xf7', '0x8f', '0xfd', '0xff']
Erasing chip...
Re-read lockbits: ['0xf7', '0x8f', '0xfd', '0xff']
Programming flash with SENSORCARD644_V7.hex
Programmed OK
Verifying flash against SENSORCARD644_V7.hex
Validated OK
Lockbits now: ['0xf7', '0x8f', '0xfd', '0xff']
Writing fuses & lockbits
Re-read lockbits: ['0xf7', '0x8f', '0xfd', '0xff']
Programming done!
```
Looks good. However, target doesn't function. So I read the flash content back again using AtmelStudio+AVRISPmk2 and this shows something is not right.
Every 0x100 bytes a block of 0xFFs appear in the read-back content, effectively being unprogrammed 'holes' in the binary.
What triggers my suspicion is that these holes all start on ..00, and their size goes from tiny to small, proceeding over medium to largish, then big - in a linear fashion. And then back to tiny to repeat the cycle.
Hole size 0 to 18 bytes.
Some kind of overrun in a counter?
I've attached a screenshot of a binary diff, exposing the phenomenon; readback on left, original on right.
AVRprog taken from Circuitpython bundle 20211024

Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the ATmega644PA chip definition and the avrprog.program_file and verify_file entry points used in the report. Reproduce the flash write and compare the programmer read-back with the original HEX around each 0x100 boundary; done means the repeating 0xFF holes no longer occur and the target contents match.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- embedded-iot, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100