The error message "Device ID mismatch" seems to be a bug.

[berkut0]

The occurrence of this error seems to be a bug, by commenting out part of the code device flashed without any struggle.

in nvmserialupdi.py:

if not self.device_info.get(DeviceInfoKeysAvr.DEVICE_ID) == device_id_read:
    self.logger.warning("ID read ('%06X') does not match expected device id! ('%06X')", device_id_read,
                        self.device_info.get(DeviceInfoKeysAvr.DEVICE_ID))
    # raise ValueError("Device ID does not match")

I got the idea from a message I got when I set the logging level to debug:

WARNING - ID read ('1E9321') does not match expected device id! ('1E9221')

Interestingly, it only differs in one number.

when you have received messages:

Device ID mismatch! Stopping.
Failed programming: uploading error: exit status 1

there might be a workaround, but I think this is the bug

Chip: ATtiny 416

[MX682X]

The 1E9321 is the chip signature for the Attiny816. As your selected chip has only less memory and otherwise the same specs, there aren't any complications. Are you sure you have the correct chip? Where did you order it form? There are cases where chips are getting re-marked, but usually the other way around (marking indicates bigger memory)

[berkut0]

@MX682X Incredibly, the Chinese factory installed 816 instead of 416. The chip is so small that I didn't check it after receiving the boards. Interesting surprise.

Thanks, that clears things up!

I should point out that the error message is a bit short on detail in such cases.

[replaysMike]

I too came across this bug. I'm using an ATTINY402, and have ATtiny412/402/212/202 selected.

pymcuprog.nvm - INFO - Device ID: '1E9227'
pymcuprog.nvm - WARNING - ID read ('1E9227') does not match expected device id! ('1E9223')
Device ID mismatch! Stopping.

it's expecting the device id from the 412 (1E9223), and complaining when it finds the device id of the 402 (1E9227). What's the recommended fix? Comment out the exception as above?

[berkut0]

@replaysMike try to build for another chip in this line. You may think you have an ATTINY402, but it's actually another chip in that line. You can look under a magnifying glass to see the mark

[hmeijdam]

You seem to set the IDE at a 202 not 402

[replaysMike]

@berkut0 that was the first thing I checked, bought all my stock from DigiKey. It looks like a 402 to me :)

EDIT: I see what the issue is - I selected the board as ATtiny412/402/212/202, but I did not select the specific chip in the Chip dropdown further down. Was not obvious lol

[berkut0]

@replaysMike I have already written above that there is something wrong with this error message, it lacks verbosity. It would be cool if the developers improved this a bit.

[SpenceKonde]

Please, by all means let me know how I can improve the error message!

Like, what could I have changed the messages to that would be clear? I've put a considerable amount of thought into how to make better error messages, because I see so many awful ones every day. But right here sort of illustrates why crap messages exist. The person who wrote the message always writes what they think will be clear, that's why we wrote what we did. But we are also obviously out of touch with reality and with how others think. *

I am a zealot over crap error messages or absent error messages (there are a lot of things that you can compile and which will never possibly do what you want, that can be determined at compile time; stock core lets this through anyway; my core tries to error on anything where your code attempts to do something is is destined to fail at. h more stuff) all in the name of ensuring that as many problems as possible can be detected and fixed without having to upload to hardware (this includes how on the Arduino IDE, with my core selected (either this or DxC), the warnings menu doesn't let you turn off warnings - that setting is ignored. >90% of warnings come from code that generates incorrect behavior, and it's far harder debug odd behavior on hardware than a compile error with an error message.

I'm pretty sure there are people who dislike me for the things I've said about another upload tools error messages, so if my error messages are bad, that is absolutely unacceptable.

* Apple used the "think different" motto for a while, though they seem to be more of a suite of products for people who think similarly to eachother these days. That aside, people really do think and process information totally differently. My mother absorbs news by having it running in the background. If I can hear a TV in the background I absorb neither and accomplish nothing. Some people find podcasts useful, or can learn to do something from a youtube video. How the fuck do they do that? I resort to videos when every other method has failed and nobody seems to have written out the instructions (invariably, what I come up with would fit hand written on a postit note, and I could have read and been done with in 5 minutes if it wasn't for video...) Anyway - most people say that that experience is totally unfamiliar to them. Likewise, to their experience of just being able to click the first youtube link about it, and absorb information and fix problems based on that? Impossible! Are they going to walk on water next? I'd say they were lying except that so many people say things like that that I can't dismiss it). The point of this diversion, other than that I hate video and television with a passion, is that when it comes with the transmission of information into the brains of humans - like writing an error message that will lead to them identifying and fixing the problem - is an extremely hard problem. Most of us have only one brain (and sometimes I wonder if that's an overestimate. Not the people on here, I mean, but in general). This means we fundamentally cannot test error messages prior to release, simply because we don't have the hardware, and we can't get the hardware unless we start kidnapping people and forcing them to use software wrong and interrogate them regarding their assessment of the error messages. That involves too many felonies and too much manual labor for me, so I must rely on my users to tell me not "This message is bad", but "This message is bad because __. You should improve it so it says ___.

So please report bad error messages - and how I can make them less bad Because at present, I cannot determine what was wrong and should be fixed.... I thought that there was no clearer way to say what I said, and have written long screeds about how much I hate the way sig mismatches are handled by avrdude on classic AVRs. I do not consider it acceptable that my messages are found wanting, this must be corrected.

[berkut0]

Hi @SpenceKonde !

It's all right, don't worry. All in all, it works well, the message isn't 'crap', it just lacks a clue as to what's going on. Add some verbosity.

For example. You seem to have selected 'chip' (expected 'id'), but 'chip' is detected on the line (was read 'id'). I don't think it's too hard to create a chip dictionary (if one doesn't already exist)