Atmel ICE detects wrong device

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

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,

 

This topic has a solution.
Last Edited: Fri. Aug 31, 2018 - 06:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are the device signature values for your t412?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

Hi Jim,

 

Device signature shows: 0x1E9223

 

although am using attiny412

 

Thanks,

Moe

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

Are you also powering it with 3.9v?  Seems odd.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

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

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

here is a screenshot, is it sort of a bug or something in Atmelstudio 7.0 ?

 

 

Thanks,

Moe

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

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

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

Hi Jim,

Thanks for the reply, I will try to look around, otherwise I shall contact MC.

 

Thanks once again,

Moe

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

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

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

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

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

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

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

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.

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

Well Done!!

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Killroymenzel wrote:

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

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

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.

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

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 !

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

I program this new AVR-Serie for the first time.

 

what is CCP exactly?

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

clawson wrote:

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

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

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.

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

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

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

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...

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

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

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

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.

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

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

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

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:

Killroymenzel wrote:
But everything I've changed in the CNTRL Register had no effect on the Timer.
then I would still suspect CCP at work if the registers really don't change when written

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

thanks for the explanation

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

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.

 

 

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

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.

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

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

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

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.

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

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.

 

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

Unfortunately, the version in Atmel Studio does not work either, as it also refers to the same Website.

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

stange, sound like a problem in the browser, because it works for me fine here.

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

Oh.....

I tried at work with IE and at home with Opera. Same Result.

With my Smartphone is this Website catastrophical

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

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!

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

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

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

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