9elements / 9elements/picoprog
faulty read
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 17
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Description
We've had several wrong reads using picoprog (+ osfc.io PCB enclosure).
This happened on reading several T540p chips.
I think it's Macronix, will send the exact IC specificer(s) tomorrow when I have the boards under my fingers.
Misbehavior took place in 2 forms:
-
successful read, followup read -> "NO EEPROM", dis- + reconnect IDC connector, successful read, followup read -> "NO EEPROM", ...
-
4M chip got read as 8M (with
-rflag even 8M saved to disk)
this happened on both flashprog and flashrom.
Note on 1.) successful reads between fuckups seem consistent, sha1sum is equal.
Note on 2.) The clips didn't move a bit. We only found that one by reverting to ch341a (after ordering new clips of course).
Haven't tried any of this against the original pico-serprog firmware. Will try soon and report back!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The report concerns picoprog reads of T540p chips, with comparisons against flashprog, flashrom, ch341a, and the original pico-serprog firmware. No source files or tests are named; first confirm the exact IC and reproduce both read failures, then compare results across the mentioned tools and firmware. Done means the read is reliable and the chip size is detected correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100