Partial use of Signature bytes to restrict processor 'type'

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't help but feel that this *must* be in the forums somewhere but I can't seem to find it ... so if this is old hat please feel free to give me a roasting and point me to the right posting!

Just finished a job for client based on the ATmega168P and to 'toughen' up their QA side of things I wanted to use the Signature bytes in the ELF file to make sure that they are targeting the correct hardware with their AVrisp Mk II.

That's all straightforward and I can do that ... pick up the signature definitions from the appropriate header, specify them in some built-everytime module and away we go...

But, turns out the client has a box full of various 168's that they want to use up on the job ... some 168's some 168P's and in due course I dare say there will be some 168A's and 168PA's floating around too.

What I'd like to do is to use just the top two bytes of the signature byte to restrict the ELF file to a generic 168 without being too sensitive to its type -- stop the real clangers where someone tries to put the wrong firmware in the wrong board altogether sort of thing.

Can I effectively get the AVrisp to check/test for say 1E/94/xx and if so how do I do it?

I'm using a fairly standard WinAVR tool chain in the development side and they're using AVR Studio 4 with the AVrisp MKII on the production/programming side.

As I say, I'm sure somebody somewhere has already done or dealt with this!

Many thanks ...

Mike.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If AVR Studio doesn't already offer this I doubt you can modify its operation in any way. However you can use avrdude to control the same programmer and apart from the avrdude.conf that can easily be edited the source is open so you can rebuild it to do whatever you like.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are using a batch file for the programming, you just cycle through the compatible signatures. Then do the actual programming with the correctly identified chip.

If it is important to identify the actual chip without a programmer, just put an identification in the EEPROM.

David.