AVR Freaks

Sorry for the delay, I'm was not familiar with that device, so it took downloading the DS to search for the signature bytes.

Looks like your AS needs updating, maybe a new device pak will correct the error.  If you have the latest version, contact MC and log a support ticket.

Jim

Try updating Studio, but what happens when you click the drop down button for DEVICE? Does the right part appear? If it does, select it and then read the device signature. If all,passes then the devices share a signature and Studio,simply picked the first match.

East Coast Jim

Well Done!!

JIm

Change Control Protection tries to ensure that "important" registers aren't accidentally altered unless you really mean it to happen. So there is a "lock" that has to be unlocked to be able to write. The lock remains open for 4 machine cycles after you write the unlock value. Can't remember off hand but I think the unlock value is probably 0xD8. So you write that to the CCP register and then, within 4 machine cycles you write the new value to the protected register. Doing this in Asm is easy (as you get to count the cycles) but C/C++ give no guarantees about the cycles any code will take. You can try to do it with two back to back writes and rely on compiler optimisation to ensure that the two writes happen in the time window. But it isn't guaranteed. For that reason the chips that have CCP (Xmega derivatives) include xmega.h as a side effect of your usual inclusion of avr/io.h. That header has:

#define _PROTECTED_WRITE(reg, value)				\
  __asm__ __volatile__("out %[ccp], %[ccp_ioreg]" "\n\t"	\
		       "sts %[ioreg], %[val]"			\
		       :					\
		       : [ccp] "I" (_SFR_IO_ADDR(CCP)),		\
			 [ccp_ioreg] "d" ((uint8_t)CCP_IOREG_gc),	\
			 [ioreg] "n" (_SFR_MEM_ADDR(reg)),	\
			 [val] "r" ((uint8_t)value))

so in your own code you just use something like:

_PROTECTED_WRITE(CNTRL.XYZ, 123);

and this will handle unlocking the mechanism and then writing the value you gave to the protected register you chose.

This is for avr-gcc/AVR-LibC, other compilers may have differing mechanisms to achieve the same.

I haven't read that chip's datasheet at all so this is all just a hunch. But the fact is that all recently released "Tiny" are really "Xtiny" chips and as far as I know they all use CCP. There's been a ton of posts recently about users writing to "CTRL" registers and the writes being "ignored". In all those cases it was CCP so I was simply commenting in #16 that this seemed likely.

Guess I need to go and read the D/S...

OK, so 2 minutes with Google later and after I typed Ctrl-F in PDF reader and said "CCP" it said:

Following the link their to "CCP" took me to:

(so I was right - it is 0xD8 when you write to IO).

Later in the D/S there are sections such as:

the key phrase in the datasheet to look for to know what has CCP protection is "This peripheral has registers that are under Configuration Change Protection (CCP)". It applies to a number of the peripherals.

It looks like it doesn't. As I say #16 was a hunch I thought it might be worth investigating. Having done that it would seem that maybe it is not the case. However I do think there is CCP protection on some of the important timer registers in other models of Xmega so it's vaguely possible this might be an over-sight/omission from the D/S. I guess the real proof of the pudding is to connect up a debugger and see what actually happens in the silicon when a value is written to one of the registers if it really is as you said: