Device ID mismatch problem

[developer-ken]

Basicly I have some ATTiny 412 chips. When I program it by UPDI, it shows the following error:

pymcuprog.serialupdi.application - INFO - Device ID from pyupdi = '1E9221' rev 'B'
pymcuprog.nvm - INFO - Device ID: '1E9221'
pymcuprog.nvm - WARNING - ID read ('1E9221') does not match expected device id! ('1E9223')
Device ID mismatch! Stopping.

The chip I am working with:

[developer-ken]

I realized that 1E9221 is the ID of Tiny416. Thats strange... (By trying over and over again with different arduino chip selections. When I select Tiny416, It finishes the whole programming procedure with no error.)

[developer-ken]

By changing 0x1E9223 to 0x1E9221 in the .py file for Tiny412, everything now works normal.

[SpenceKonde]

The 412s that you got are defective/fake/mismarked. Others who have gotten those chips report that they do not work correctly (ex, they have been unable to get the USART to work at all on any pins). We have a warning about this in the documentation. This is why you should only purchase the modern AVRs from reputable vendors located in western countries with a functioning rule of law, never from aliexpress/ebay/similar. On the rare occasion that the ebay/aliexpress vendors advertise these parts, they are highly likely to be bogus, like the ones you have. My theory is that a batch got programmed improperly in the factory calibration step (it is widely believed that the same die is used for multiple parts, for example, 1its nearly certain that the 3216 and 3217 use the same die - and that part of the "factory calibration" process involves telling the die what chip it's going into); discovering their error, Microchip tried to discard them, but some enterprising crooks somehow obtained the discarded ICs and started selling them through shady aliexpress storefronts. But that's just a theory. Microchip has thus far shared no actual information on these mysterious parts. Surprised they're still making the rounds... they last surfaced quite a while ago.

[developer-ken]

Thanks very much. I will buy some new chips from a reputable vendor. But before that, I found another problem

The chip not performing a power-on reset, so I can only make it work by a updi reset every time. Is this problem about what I did wrong in my design/arduino settings or is related to this abnormal chip?

[SpenceKonde]

On what grounds do you conclude that it is not performing a power on reset?

If you are looking at the reset flag register, that's expected - in fact, if you ever saw a reset flag set from your application code, you're in a cant-happen land, and bad things are bound to occur..... Prior to setup (or even init()) being called, we check clear, and store a record of the reset flags that is accessible to the application, please read the reset documentation: https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/Ref_Reset.md That describes why in recent versions of the core, the reset flag register will always appear empty from user code, and how the change in question was necessary to ensure that bootloaders honored the entry conditions supplied by users and to help prevent crashes and hangs.

If these bogus chips also don't do a POR cycle.... good lord... At least their QA team caught that before they made it customers.

[SpenceKonde]

Oh and I did just confirm that my theories would prectict the 416 and 412 to use the same die, bolstering my misprogramming theory.

[developer-ken]

Thank you very much. When talking about "The chip not performing a power-on reset", I mean they don't do POR so won't actually do what I programmed, untill I reset it manually. I found these chips sometimes POR, in rare cases not.. maybe they are malfunction. Some new chips from my friend solved the problem.

Thanks for your answer again.

[SpenceKonde]

Interesting indeed!

[SpenceKonde]

POR has a very specific meaning. You seem to be using it to mean "none of my code executes when power is first supplied" - which could certainly be a consequence of some sort of malfunctioning reset) but , a POR is a very specific process that happens when the voltage crosses a certain threshold, thhe chip becomes briefly nonresponsive while all SFRs are reinitialized to the power on reset states. and then the resent condition is automatically released when this is done with program exxcution commencing from 0x0000, the "reset vector"./ There are no shortage of things that can cause code execution to proceed in the manner you expect, likely due to assumptions relied uipon by user code which are not always true. But in any event, ANYTHING that a 412 that thinks it's a 416 does should be treated as highly suspect and probably should not be used at all.