adafruit / adafruit/Adafruit_CircuitPython_AVRprog

Flash-write repetitively missing bytes on 0x100-boundary

Open
#23 5 comments 0 reactions 0 assignees View on GitHub
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

![InputVsReadbackComparison](https://user-images.githubusercontent.com/5655097/139692007-29aeaaf5-4c6e-41bd-89f3-0a32cd613d66.png)

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.