lock bit in xmega

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

Hi.

I need to lock my code in xmega128A1 to protect my code and prevent it being read back. so I set the lock bits like image below:

but I still can read my program! could you please help me ?

 

 

This topic has a solution.
Last Edited: Sat. May 16, 2015 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may read SOMETHING but it's usually garbage, check the data you read back.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

You may read SOMETHING but it's usually garbage, check the data you read back.

 

No it is not garbage! because after I read data from xmega, Programed it again with that hex file and still working!

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

 Did you look at the data in the hex file that you read from the chip?  It's a text file. 

 

When you programmed it again, did you do a chip erase first?  Did you verify the chip erase erased the flash?

Last Edited: Sun. May 17, 2015 - 12:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, did you actually hit the "Program" button to write the lock bits to the uC?

 

JC

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

DocJC wrote:

 did you actually hit the "Program" button to write the lock bits ?

 

JC

The picture in the first post seems to say he did.

 

 

The best question is "are the locks still enabled?".  If so, the write of the hex file gotten by the read of flash, did nothing.  This assumes the locks really work, but maybe they don't.

Last Edited: Sun. May 17, 2015 - 08:10 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

blush

Good point, Steve.  I guess I wasn't paying close enough attention.

 

I noticed, also, that the Xmega is the 128A1.

 

If that was one of the first version Xmegas then perhaps the Lock Bits don't work, as there were a fair number of silicon issues on the early chips.

 

I think I still have one 128A1 PCB around.  If so I'll give it a quick try.

 

JC

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

DocJC wrote:

I noticed, also, that the Xmega is the 128A1.

JC

A good catch.  I didn't notice.  I think it is wise to assume whatever you want to do with that chip, probably doesn't work.

 

Use the 128A1U or suffer.

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

DocJC wrote:

blush

Good point, Steve.  I guess I wasn't paying close enough attention.

 

I noticed, also, that the Xmega is the 128A1.

 

If that was one of the first version Xmegas then perhaps the Lock Bits don't work, as there were a fair number of silicon issues on the early chips.

 

I think I still have one 128A1 PCB around.  If so I'll give it a quick try.

 

JC

 you are right! I think there is a problem with xmega12A1 ! :(

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

I think

Based on what?

 

I've googled and can find no evidence to suggest that there was ever a problem with the 128A1 lockbits. What have you found? Has the support line at atmel.com confirmed it is a known issue?

 

I still bet that the .hex you read out contains rubbish. Did you actually look at the bytes in it? I just built an "empty" program for Xmega128A1. the first few lines of the .hex look like this:

$ cat avr.hex
:100000000C94FA000C940A010C940A010C940A0155
:100010000C940A010C940A010C940A010C940A0134
:100020000C940A010C940A010C940A010C940A0124
:100030000C940A010C940A010C940A010C940A0114
:100040000C940A010C940A010C940A010C940A0104
:100050000C940A010C940A010C940A010C940A01F4
:100060000C940A010C940A010C940A010C940A01E4
:100070000C940A010C940A010C940A010C940A01D4
etc.

There's a fairly obvious pattern to that. They are all AVR JMP opcodes. Now in your program the jump destinations will be different so the target offsets in the opcodes will differ but the reset/IVT at the start of any valid Xmega program is going to look somewhat similar. Here's another example...

~$ cat avr.hex
:100000000C9438010C9448010C9448010C9448015C
:100010000C9448010C9448010C9448010C9448013C
:100020000C9448010C9448010C9448010C9448012C
:100030000C9448010C9448010C9448010C9448011C
...

(I just added a block of PROGMEM to offset the jump targets)

 

Does the first few lines of the .hex you read out of the Xmega look ANYTHING like these examples. If not it is not valid AVR code.

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

clawson wrote:

I think

Based on what?

 

 

because I try this with xmega32A4u and it worked when I read that I got this code:

 

:1000000000000000000000000000000000000000F0
:1000100000000000000000000000000000000000E0
:1000200000000000000000000000000000000000D0
:1000300000000000000000000000000000000000C0
:1000400000000000000000000000000000000000B0
:1000500000000000000000000000000000000000A0
:100060000000000000000000000000000000000090

 

but in my xmega128a1 did not work!

but I try with another xmega128a1 and inform the result here.

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

clawson wrote:

I've googled and can find no evidence to suggest that there was ever a problem with the 128A1 lockbits.

 

Probably you didn't google enough :)

Here is the same problem (as I can understand)

 

http://www.mikrocontroller.net/t...

 

It seems that it is not an issue of a chip, but a programmer mkII

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

How can the "bad" parts be identified? I'm having some wierd problem with an A1.

Thanks

madGambol

 

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

A1 bad, A1U good.

 

The A series (without the U) has been discontinued, at least I hope so.  Consider them beta test Xmegas.

 

 

Last Edited: Wed. May 27, 2015 - 08:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Steve17.

 

I have an ETT XMEGA128A1 board. I can't say the hardware is at fault, but I'm getting weird failures --- very intermittent, most visibly with the I2C. I'm not sure how to debug the problem when I can't reproduce it. Things seemed to improve a little after I locked the system clock.

 

The main symptom is that the I2C channel I wrote the code for (using the sample twim.c as a guide) hangs after some events. Mostly when the board gets busy. I don't know how to debug this; the next interrupt for the I2C channel doesn't happen -- then I2C data stops.

 

The part on the board says:

 

ATXMEGA128A1

AU 1123

 

I have a spare with the date code 1234. That "AU" isn't part of the part number, is it?

 

Thanks,

madGambol

 

 

 

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

The AU is not part of the part number.  It is the package type.  You have the obsolete Xmega.

 

I don't know anything about your I2C problem.  I've never used it.

 

EDIT:  I guess the I2C problem is likely not due to a silicon bug in the 128A1, so you might want to start a new thread.

 

 

Last Edited: Thu. May 28, 2015 - 10:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I happen to have a "datasheet" for the Xmega128A1 rev. H and rev. G.  This one is doc8067.pdf.  They didn't call them datasheets back then, but they are not what they call a manual which is for the whole series.  I notice several errata for TWI which may be another name for I2C for all I know. 

 

 

 

 

 

 

Last Edited: Thu. May 28, 2015 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's good information, but I don't think its explains my problem.

 

I'm doing a read, and the interrupt that should complete the i2c action and take the last byte doesn't occur. It appears that the RIEN bit is cleared by something. I'm now trying to figure out what.

 

I have attached a plot of the significant events.

TIMER0: the periodic timer kicking off the I2c transfer

I2C Restart: the routine that restarts the I2c

I2C Tickle: sends the address 

I2C INT: TWID ISR

Notify: when the transfer is complete, this is called to set a flag saying so.

SDA press: SDA line for the I2C i/f

SCL press: SCL line for the I2C i/f

 

  1. "I2C Tickle" start transferring the address
  2. The address is ACK'ed
  3. The first byte of the 2 byte read arrives and is ACK'ed
  4. the next byte starts
  5. The expected interrupt for the 2nd byte doesn't happen.

 

The mystery is: why doesn't the interrupt trigger?

 

BTW, that's a Saleae LogicPro 16 output. I shut off other channels.

 

Thanks,

 

Attachment(s): 

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

madGambol wrote:

...snip

The mystery is: why doesn't the interrupt trigger?

...snip

 

That's the last of many successful i2c reads, hence the mystery.

madGambol

 

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

I found the problem. This is a duplicate explanation from another thread.

 

In the larger context of my environment, I was dumping a status history gathered in the I2C driver and THE CURRENT STATUS of the interface in my debugging serial interface. That was the problem. By asynchronously reading the DATA register I was changing the state of the interface against the interrupt service routine, and that was causing the end of the I2C interrupts. The I2C hardware was fine. My bad handling of it was causing the trouble.

 

Thanks for the suggestions!

 

madGambol