ATTINY402 and UPDI Grief -- Reads as TINY406

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

New to the Tiny 402 family  and thus new to UPDI
I have implemented the chip on my own hardware. 3v3 regulator,  decoupling,  Tiny402 and that's all,   but I'm having a struggle.
I've not used the Tiny 402 before, so I've had to update AVR studio to Microchip Studio latest, install the required CPU pack etc, upgrade the AVR ICE firmware.. all done.
The crazy thing is, fresh new out of the tube devices are reading back as Tiny 406 devices.
I can change the bit rate and I can see it changing  it looks nice and clean, same result from 32Khz to 500Khz.

I have some code that I need to flash, but it uses the UPDI pin as a port, so I don't know whether to risk loading it regardless in case it locks out the updi port.

I don't know if the new Tiny can set the fuses to lock out the updi and I'm stumped by reading back as a tiny406.
I've tried to decode the UPDI data , but no luck finding a working bit time/ baud rate that gives sensible data.
I've downloaded the memory  it's full of 0xFF

I've downloaded the fuse map.. works each time.. attached you can see what it reports. Clearly it is NOT a 406  it only has 8 pins.

 

This is what I ordered from RS Components.Microchip ATTINY402-SSFR, 8bit AVR Microcontroller, ATTINY, 20MHz, 4 kB Flash, 8-Pin SOIC

Generally, I know what I'm doing, the UPDI waveform looks good, the chip is decoupled nicely,  but having spent a whole day now trying to find out why it loads as a tiny406, I thought I'd check here for pointers.
 

Attachment(s): 

Last Edited: Sun. Jan 17, 2021 - 05:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I feel your pain with the SW and data pack upgrades, I did that recently, also...

 

I used the SNAP programmer instead of the ICE.

There were several notices that the SNAP needed a 4.7K pull-up resistor added to the UPDI line for it to work.

I put it on my PCB, one of the notes talked about just putting it on the SNAP programmer itself.

 

I don't know if the ICE needs that modification or not, but do look at the MicroChip notes on the ICE to see if you see any comments in that regard, or just try it, it won't damage anything!

 

My T402's read the Signature correctly in Studio.

(Disclaimer:  I didn't look at the Signature data, I just selected the T402 and it said it read it correctly!)

 

Obviously you will want to read the Signature correctly, and program a simple LED flasher, and have it work, before you go mucking about with the UPDI pin modes and the potential inability to easily re-program the chip.

 

Once I had the SW updates completed, (a chore...), using Studio, the SNAP, UPDI, and the T402 worked flawlessly, and easily.

 

JC

 

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

According to my datasheet the Signature bytes should be 1E 92 27

ATtiny402 0x1E 0x92 0x27

And the ATtiny406 datasheet says:

ATtiny406 0x1E 0x92 0x25

So I would panic.  

 

Mind you,  you should be able to compare datasheets and see which one's registers behave according to which datasheet.

 

In other words,   build a project for tiny406 because that is what the Signature says.   And UPDI will access the tiny406 registers when debugging.

 

On the other hand,  wait for a bit.   I am sure that other members have tried the t402 and the t406.    I have not.

 

It is a mystery why anyone would start with an SOIC-8.   Much easier to start with a chip that is better endowed i.e. with more legs.

 

David.

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

rowifi wrote:
I have some code that I need to flash, but it uses the UPDI pin as a port

That choice can result in the "I shoot myself in the foot" now what do I do, but it's your foot, so tread lightly! (pun intended)

Better to pick an AVR with enough pins so you don't have to use the reset/updi pin!

IIRC it takes HV (ie 12v) pulse to undo, and restore updi functionality, will the circuit on that pin take 12v without damage?

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

I would be confident that PA0 is present on your chip i.e. UPDI pin.

Or else the Signature could not be read.

 

The 402 and 406 have different multiplexing on the GPIO pins.

So you can identify whether you have a 402 with wrong Signature or a 406 with wrong package.

 

Simply phone RS and they will send you replacement ATtiny402

 

I have downloaded a combined datasheet DS40002159A (Dec 2019) that says:

7.7 Signature Bytes
All tinyAVR® microcontrollers have a 3-byte signature code that identifies the device. The three bytes reside in a
separate address space. For the device, the signature bytes are given in the following table.
Note: When the device is locked, only the System Information Block (SIB) can be accessed.
Table 7-4. Device ID
Device Name Signature Bytes Address
0x00 0x01 0x02
ATtiny204 0x1E 0x91 0x22
ATtiny202 0x1E 0x91 0x23
ATtiny406 0x1E 0x92 0x25
ATtiny404 0x1E 0x92 0x26
ATtiny402 0x1E 0x92 0x27

David.

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

>so I've had to update AVR studio to Microchip Studio latest

 

You could double check by using MPLABX if wanted. Doesn't seem likely that it would be any different, but...

Can skip the xc8 compiler download after install and use the existing compiler you already have in studio (somewhere in Program Files I assume)- tools, options, embedded, build tools, point to avr bin folder to add it.

 

edit- this is meant to simply eliminate any problems that may be from the ide, however unlikely.

Last Edited: Mon. Jan 18, 2021 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its not my code. Its opensource i2c encoder. I'm cheating for this part of the project, but the sample modules I bought work fine. So the simplest thing.. is causing untold headache.
I have more chips, but its a 8 pin device, marked 402 yet the id is 406.
Nothing is intermittent, i get repeat data when loading flash, fuses etc.. the waveform looks very clean.

Last Edited: Sun. Jan 17, 2021 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

The 402 and 406 have different multiplexing on the GPIO pins.
So you can identify whether you have a 402 with wrong Signature or a 406 with wrong package.

You can sort out the answer within seconds.
Farnell would replace your chips within 24 hours.   I guess that RS would too.

 

David.

 

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

So.. I had to build a program based on the ATTINY406, because Studio wouldn't upload to a 402 type device ...

Of course, nothing is simple.. but having created a simple program using Start and ASF4 9 (how else to get the io working quickly when you've not used these devices before!!)

Well, it loads and runs and from within debug I can see the Device ID which confirms a Tiny406. 1E 92 25.

 

From datasheet ATtiny406 0x1E 0x92 0x25

The fact I can load code and debug it  would suggest my updi connection is ok.

Now .. I suppose I have to work out how to toggle io pins using ASF4 ( < Swear> )

 

*Edit.  Setting PA7  to toggle  gets PIN3 to toggle which PA7 on the 402 ...  and it toggles.

 

io

Last Edited: Mon. Jan 18, 2021 - 02:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rowifi wrote:
Now .. I suppose I have to work out how to toggle io pins using ASF4 ( < Swear> )

PORTx.toggle = (bitmap of pins to toggle) //where x = port name A,B,C,D, etc....

PORTx.set  = (bitmap of pins to set)

PORTx.clear = (bitmap of pins to clear) 

 

nothing complicated with AVR's!

 

 

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

Have you told RS yet?

 

You would receive the replacements tomorrow.   (assuming you are in the UK)

 

Regarding the problem.    Just look at the multiplexed pins in the debugger.

 

No,  I would not use Start or ASF.    It would take you forever to follow what they might do.

Literally,   just write a very sparse main(),  step a couple of instructions and  view the IO registers.

 

David.

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

It's not the first time this issue pops up. Here are some links with some information:

 

https://github.com/ElTangas/jtag2updi/issues/12

https://www.avrfreaks.net/comment/2577346#comment-2577346

https://www.avrfreaks.net/forum/attiny-202402-was-simulator-issue-now-bad-device-id

 

Basically, yeah, the chips are defective and should be replaced.

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

I presume that there was a whole batch of ATtiny402 with the wrong Signature.   You can read the data code and Fab from the chip package markings.

 

El Tangas will know if current production chips have the correct Signature.

 

Meanwhile,  you tell RS.   They mail you the correct chips.   The will not ask you to return the duff chips.

You just add a special "t402duff" entry to avrdude.conf

 

Since this "problem" first occurred in 2018 I would have thought that RS would have shifted the duff stock 2 years ago.

It is the sort of "bonus" that you would expect from Ebay .... not RS.

 

David.

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

I'm simply used to ORing bits to the PORT register, and having used a 'Framework' for the ST chips.. Toggling pins never seemed to be as simple as a nice OR or AND. Maybe I need to move to 2021.

Further along this project - although not really positively, I've opened a case with Microchip regarding the Device ID.
That aside,  I risked loading in the encoder program ( not mine ) and it failed to .. well, I'm not sure, it won't talk on debug anymore, so the UPDI port is well and truly locked out. Perhaps the code loaded, run a bit and stuffed the UPDI port for it's own purposes although the docs stated that the pin could be used for debug.

This is the project FWIW  https://github.com/Fattoresaimon...

I did think that UPDI could always be recovered/accessed unless a fuse was set .. and I read that you can't set the fuses from within the program, and I didn't think debug mode set the fuses.. Yet I now can't read the chip at all.. this is now chip number 2 that I've tried this on... into the tin it goes...
I've ordered more chips... from Farnell this time.

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

El Tangas wrote:
It's not the first time this issue pops up. Here are some links with some information:

 

Oh right!! Thanks for finding that.

I have spoke to RS, but of course... need to wait for an engineer to understand me.
I will try the Farnell chips tomorrow.

 

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

Go on.   You quote your invoice number.   Quote the date code on the chips.   Explain the problem.

No one will quibble.   RS will just mail replacements.

 

Ok,   someone from RS might investigate at a later date.    But first off,  they will keep the customer happy.

 

I have no idea what your project does.   But it certainly looks complicated for a single I2C Slave.

 

You don't need to know what the chip markings mean.   Just read them and type them to your message.

 

David.

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

david.prentice wrote:
El Tangas will know if current production chips have the correct Signature.

 

Actually I'm not sure... All I know is, last time I had knowledge of these faulty chips circulating in the wild, was May 2020... supplied by RS Australia.

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

Here's another question - -perhaps worth of a separate thread, but since it's related to my current issues, I'll ask here..
 Can compiling and loading a project then simply executing the debug mode , cause the fuses to be set?
I never thought it possible, ( always assumed it was a manual job using the programmer) but the author says that's what his code does and would explain why I brick the devices after trying to debug.

e.g.

 

Yes my code configure the fuse:

#define f_APPEND  0x00
#define f_BODCFG  0x50
#define f_BOOTEND  0x00
#define f_OSCCFG  0x02
//#define f_SYSCFG0  0xF4 //UDPI MODE
#define f_SYSCFG0  0xF0 //GPIO MODE
#define f_SYSCFG1  0x03
#define f_TCD0CFG  0x00
#define f_WDTCFG  0x00

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

From memory,  when I glanced at the GitHub.   The author sets fuses in the source code.

 

If you choose to shoot your foot.   Your foot will hurt.

 

You need UPDI mode to upload code to the chip.

If you set fuses for GPIO mode,  your application should run but you will no longer be able to debug or re-program.

The ATMEL-ICE can not reset the UPDI mode because it requires High Voltage.

 

It looks a bit like debugWIRE feature.   i.e. you can debug, re-program, ... but as soon as you set RSTDISBL to make dW pin into a GPIO pin you are dead.

 

Quite honestly.   If you intend to use the UPDI pin (or debugWIRE pin) as GPIO in your application:

1. Develop on a bigger chip.

2. Rebuild for the small target chip.

3. Finally upload the fully debugged program to the small target chip.

4. Disable RESET pin.

 

If you are simply using a proven project.   You buy cheap tiny402 chips.   You start at (3).    Forget any possibility of ever doing (1), (2) on that chip.

 

There is nothing wrong with choosing a leg-starved chip.    Just don't expect to re-use it after crippling the RESET pin.

Treat any "use RESET pin for GPIO" project as a OTP chip.   (One Time Programmable)

 

David.

 

p.s.  the "shoot foot" feature is impractical to recover on a debugWIRE chip.   It needs HVSP or HVPP programmer.

At least UPDI can be recovered (but not with an ATMEL-ICE)

Last Edited: Tue. Jan 19, 2021 - 10:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just so you know, their is a bunch of chips out there in the wild with wrong device ID's, I have some too. microchip made a buch and set wrong device id's and shipped them to various suppliers. I confirmed this via a support ticket with microchip.

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

@12oclocker,
@rowifi,
.
Please post the datecodes of your duff chips.
And the datecodes of your new chips from Farnell.
.
This would help anyone else in a similar situation.
.
David.