Dear All,
I have an ATTINY412 on a custom PCB. However when i set the target device to the ATTINY412 to flash the program, the ATMEL ICE detects its ATTINY402. I checked the pic compatibility on the datasheet and it looks pretty similar, does anyone knows why the programmer cant detect the right MCU ?
Thanks a lot,
What are the device signature values for your t412?
Jim
Hi Jim,
Device signature shows: 0x1E9223
although am using attiny412
Thanks,
Moe
Are you also powering it with 3.9v? Seems odd.
Jim
yes. Well, I have a Li-ion battery connected to it, 3.7v/850mA, Atmel ICE was only supplying 0.2 V, so i coudnt flash the program to my PCB. i am using UPDI as stated in the datasheet for new ATTINY.
Thanks,
Moe
here is a screenshot, is it sort of a bug or something in Atmelstudio 7.0 ?
Thanks,
Moe
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
Hi Jim,
Thanks for the reply, I will try to look around, otherwise I shall contact MC.
Thanks once again,
Moe
jgmdesign 
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
Hi EC Jim,
Well, the thing is if clicked on the right part (in my case its: ATTINY412), i get an error that the device signature doesnt match and the right device should be ATTINY402. funny part is, although flashing the program works really fine till now. the ATTINY412 and ATTINY402 are quite similar so far.
everything is up-to-date. so I have no idea whats wrong...
if anybody stepped in the same situation, then he is welcome to contribute. or also any suggestions.
Thanks all,
Moe
Hi everyone,
Just a small update/solution for the users of this MCU, today I got a reply from the microchip support and indeed it was a fault signature which is found in in the attiny412 atdf's signature, so here is the reply I post it like it is:
********************************************************************************
The part pack file(version 1.3.172) of ATtiny412 and ATtiny402 contains wrong device signature value.
As a workaround you can manually correct the signatures in the ATDF files.
You find the ATDF files here: C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.172\atdf
The correct signature for ATtiny412 is 0x1e9223. If you edit the file ATtiny412.atdf lines 320:324 should look like this:
<property-group name="SIGNATURES">
<property name="SIGNATURE0" value="0x1E"/>
<property name="SIGNATURE1" value="0x92"/>
<property name="SIGNATURE2" value="0x23"/>
</property-group>
The correct signature for ATtiny402 is 0x1e9227. If you edit the file ATtiny402.atdf lines 301:305 should look like this:
<property-group name="SIGNATURES">
<property name="SIGNATURE0" value="0x1E"/>
<property name="SIGNATURE1" value="0x92"/>
<property name="SIGNATURE2" value="0x27"/>
</property-group>
******************************************************************************************
So I edited the signature and so far it looks fine.
Regards,
Moe
Hi Moe,
Many Thanks for solving this problem.
I had the same problem last Weekend.
And I hope, my other Problems with the TCA will solved either.
jgmdesign Well Done!!
JIm
Hi Moe,
Many Thanks for solving this problem.
I had the same problem last Weekend.
And I hope, my other Problems with the TCA will solved either.
You are welcome. Whats the problem of the TCA ?, remember in ATTINY412 there is only one peripheral for PWM/TCA which is PA3 (WO3) (Check Datasheet, Page 14). one might think that ATTINY202/ATTINY212 OR ATTINY202/ATTINY412 are similar, however they are quite different in structure. apart from the pin numbering, both series varies greatly. while ATTINY202/ATTINY402 offers two instances for PWM/TCA e.g. TCA0 & TCB0 with more than 5 peripherals for PWM. this is not possible on the tiny 1 series.
if you already done your prototype with the wrong peripheral for TCA i suggest you short the pin of TCA to the pin you would like to you for generating PWM. chekc this tutorial sheet, specifically page 37.
I hope it helps,
Regards,
Moe
I'd used the TCA0 only in normal mode with Overflow Interrupt.
But everything I've changed in the CNTRL Register had no effect on the Timer.
clawson 
But everything I've changed in the CNTRL Register had no effect on the Timer.
I program this new AVR-Serie for the first time.
what is CCP exactly?
Killroymenzel wrote:
But everything I've changed in the CNTRL Register had no effect on the Timer.
Sounds a lot like you aren't doing CCP !
Okay Clawson,
We are all struggling with this new series, could you clarify for us as a matter of steps how to do it ?
You can read the documentation all over again, but a lot of things are missing, so if you have any suggestion please let us know.
Regards,
Moe
clawson 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.
So Clawson, allow me my question sounds basic. if i understood you right, what you suggest is that the TCA0 driver has somehow locked regsiters for "safety" reasons. some of these registers are the TCA0_CTRLA,B,C,D...etc ?. where is this written in the datasheet of ATTINY212/412 ?
Regards,
Moe
clawson 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...
Yes, I do appreciate your efforts, its just this is all seems like a black box to us. neither mentioned in the datasheet+recently released, I dont understand when things are not mentioned in the product datasheet and they want to market it. funny and sad at the same time!
Regards,
Moe
clawson 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.
Totally clear, but where is it written in the TCA/PWM driver section, there is the initialization of TCA/PWM drinver in the same datasheet, and its not written there. I'll give it a try and paste my feedback here.
Thanks again,
Regards,
Moe
clawson 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:
But everything I've changed in the CNTRL Register had no effect on the Timer.
thanks for the explanation
After I written 0xD8 in the Register CPU_CCP, I have acces on the Clock-Register. But on the prescaler of the TCA0 it has no effect.
In the Datasheet I could not see a connection between CPP and TCA0.
I agree.
Before microchip bought atmel, the datasheets were better structured.
And for every shit there was an example in C and assembler.
I miss this time.
Before all that I program in assembler.
Hi Kellroy,
This is what I was trying to say, you read the datasheet of this part for initialization of TCA0, you do the steps...you flash and guess what, nothing happened ? Why, myabe because there is a part that is completley not mentioned in TCA0 but mentioned in another place without reference to TCA0 has to be done first (you must be smart) otherwise start programming/debugging for another month without reaching results.
anyhow, have you checked the tutorial from MC that I mentioned it ? it uses Atmel Start, its a good way to go through the initilization process, also setting the PRESCALER.
Good luck,
Regards,
Moe
Hi Moe,
The Problem I had, is the Atmel.start . It doesn't work.
I want to initialize my peripherial in steps in Assembler.
The start.atmel.com loads and loads and loads. If i klick on the Timer0 to config - it starts loading and nothing happends.
I want to program my processor, not a tool that only works over the internet.
This kind of development is going in the wrong direction in my opinion.
Hi Kellroy,
For sure i do understand. its just a way to see the background of the initialization. You know, we have bad datasheet, new part...so.
As for this Atmel.start, another way is to use it directly from Atmel Studio (If you are using it). File --> Atmel start project. maybe it works.
Unfortunately, the version in Atmel Studio does not work either, as it also refers to the same Website.
stange, sound like a problem in the browser, because it works for me fine here.
Oh.....
I tried at work with IE and at home with Opera. Same Result.
With my Smartphone is this Website catastrophical
Checking in to say I also just ran into the "thinks a 412 is a 402" problem. Delighted to see a solution posted - many thanks!
Dear All,
Just a small update concerning the XOSC32CTRLA register, maybe the people who were using this Attiny series have noticed that it was not implemented this is due that the older ATTiny_DFP 1.3.172 doesnt include, they also have some typos in the library, hence try to update to the latest version where they fix these errors. Latest version is 1.3.229.
if you have an error updating ur atmel studio, you can download it manually through: http://packs.download.atmel.com/ , here you can see that indeed they had a lot of typos:
I know that this has to be in another post, but lets take it as a follow up...
Regards,
Moe
I strongly recommend updating ATtiny DFP pack to 1.3.229, because you will ran into other several issues from my experience.
You are welcome