Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for ATtiny26, ATmega640, ATmega128x and ATmega256x #284

Merged
merged 6 commits into from
Sep 26, 2021

Conversation

attie
Copy link
Member

@attie attie commented Sep 23, 2021

This patchset adds support for programming ATMega640, ATMega128x and ATMega256x parts

  • Fix a bug when calling range() for verification - the chunks appear to be broken into 64K pieces, which may have been masked on parts with smaller memories.
  • These new parts make use of a "Load Extended Address" instruction, to reach beyond the 17-bit limit imposed otherwise
  • These new parts have 8-byte / 4-word EEPROM pages
  • Add definitions for these parts

The "Load Extended Address" instruction is present in the datasheet for the 328p, and I have confirmed that it doesn't have any adverse side-effects when receiving it... I can't make that claim for other parts, but could probably dig out a couple of other parts...

This has been tested against a 328p, and a 2560.

@attie attie requested a review from whitequark September 23, 2021 23:45
@whitequark
Copy link
Member

This broke the test test_api_program_memory. Can you take a look?

@attie
Copy link
Member Author

attie commented Sep 24, 2021

Ah, yes... apologies - done!

@@ -122,6 +131,7 @@ async def load_program_memory_page(self, address, data):
data)

async def write_program_memory_page(self, address):
await self.load_extended_address_byte(address)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm: you've verified that this should happen for all devices, and won't lead to issues on those which do not use extended addressing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not actually tried it on all devices, but I have confirmed that according to the datasheet, devices like the ATTiny24 and ATMega168 support this instruction.

I have tested this against an ATMega328p, and I think I could dig out an ATTiny24 (possibly also 85) to try / confirm too if you'd like.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be nice if you can!

Copy link
Member Author

@attie attie Sep 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ATtiny85 was fine.

I couldn't find an ATtiny24, but did find an ATtiny26, which A) doesn't support this instruction, and B) needs another fix... push incoming

@attie
Copy link
Member Author

attie commented Sep 25, 2021

I've reworked this PR somewhat...

Extended Addressing

For all devices upto and including 128k, we don't need to use the extended addressing... the natural reach of the base addressing is 2^17 = 128KiB.

Unfortunately, for the larger parts, it seems that we need to use the "Load Extended Address" instruction, even for the lower pages... I don't quite understand why, but without it the higher pages don't write properly - so we can't just omit it until we cross into the higher pages.

All the parts that I've looked at (including ATtiny85) are documented as supporting this instruction, except the ATtiny26 - there may of course be others.
Although the ATtiny26 datasheet doesn't explicitly list this instruction, it is either cleanly ignored or handled correctly, meaning that issuing it does not cause an error.

If it would be preferred, then I can add a flag to the database, but I don't believe it's necessary.

"Poll RDY/#BSY" Instruction

I managed to dig out an ATtiny26, which appears to have an older/reduced version of the protocol.

It doesn't claim support for the extended addressing, and it also doesn't support the "Poll RDY/#BSY" Instruction...
This means that erase / program operations either get truncated (during chip erase) or don't complete before we try to move on (during programming), leading to garbage in the memories.

I've added an erase_time field, which allows us to specify a worst-case time for these operations, and allows us to program this device successfully.

Testing

This PR has now been tested successfully on the following devices:

  • ATtiny26 (small blinky, full 2k + verify)
  • ATtiny85 (small blinky)
  • ATmega328p (small blinky)
  • ATmega1280 (small blinky, full 128k + verify)
  • ATmega2560 (large application, full 256k + verify)

@attie attie changed the title add support for ATMega640, ATMega128x and ATMega256x add support for ATtiny26, ATmega640, ATmega128x and ATmega256x Sep 25, 2021
Copy link
Member

@whitequark whitequark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you for this wonderful PR!

@whitequark whitequark merged commit 2f48a32 into GlasgowEmbedded:main Sep 26, 2021
@attie attie deleted the atmega2560 branch September 26, 2021 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants