Creaing a production file that also includes lock bits (avr32da devices)

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

I found a same question here

https://www.avrfreaks.net/forum/...

 

but they are talking strangely about programmers and not about the way how the production file can be created. It's clearly not possible to create such a file using microchip studio 'device programming' dialog. As the result one would have to flash the FW and then switch to Lock bits tab and set them.

They are also meantioning an 'atprogram' utility here https://ww1.microchip.com/downlo... This tool can set a security bit for arm and UC? devices, so not a match

avrdude can write lock bits but last time I checked it didn't support 'da' devices.

 

We are using atmel ICE debugger over UdPI

I could try to define a value in source code under 0x1040... where the lockbits are, but then I have to maintain 2 FW files which can be confusing for production people.

 

Well, I mean it should be easily done, am I missing something? (A solution with a batch file that does FW programming and setting Lock bits in several steps is also acceptable)

Thank you

This topic has a solution.
Last Edited: Fri. Jun 10, 2022 - 04:48 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

You can write lock bits in the source code.
The description is strange because lock.h has not yet considered the DA series.

I don't know a smarter way.

#include <avr/io.h>

// LOCKBIT
unsigned long __lock LOCKMEM = LOCK_KEY_RWLOCK_gc;

int main(void){
    while (1);
}

 

 

You can see that the elf file contains Lockbits.

Whether to write lock bits depends on the contents of the batch file.

 

 

Last Edited: Mon. May 23, 2022 - 09:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

atprogram example:

atprogram -d AVR128DA32 program -lb -f xxxx.elf
 

If you remove -lb, Lockbits will not be written.

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

As suggested by kabasan I added

unsigned long __lock LOCKMEM = LOCK_KEY_RWLOCK_gc;

surrounded with a preprocessor macro and created another compilation configuration called production (debug/release/production) which activates that macro