Month: April 2021

ATTiny84 Issue Figured Out

I’m so glad I bought a logic analyzer a while back. It’s made figuring out the issue I was having so much easier. As I wrote the other day, my ATTiny84 no longer responded to AVRDude. I checked by programmer by uploading a basic blink test to an ATTiny13, and confirmed that the programmer itself was fine. I double-checked connections, and they are all set up. So, it was time to hook up the logic analyzer to see what was going on.

Figure 1: Standard AVRDude AVR programing initialization (the unexpected bytes are common for my setup, and I have no idea why).

I hooked up my logic analyzer to the breadboard setup to check what the ISP programming looks like and what’s happening. Using PulseView, I got the result above. The decoder tells me that the signals being sent are the standard programming enabling command, so I know that the USB programmer is sending the usual commands. Whenever I’ve used the logic analyzer, I’ve always had those unexpected bytes in the reply. I’m not sure why they show up, but I’m sure it’ll have something to do with me not setting things up correctly. Either way, I got those with a succesfull programming sequences as well, so I’m not too worried.

Figure 2: silence on the wire

It’s after the programming enable message that the interesting thing happens; or, more specifically, doesn’t happen. The reset pin gets a high signal, to ready the ATTiny84 for programming, followed by nothing. The LED being powered by the chip doesn’t even turn off as I’d expect it to do when the chip fully resets. This leads me to conclude that the reset pin just isn’t responding. That would make sense, given the AVRDude error message:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

This is exactly what I’m seeing, as the programmer is trying to initialize, but it seems to be failing at the reset stage. I assume the programmer would expect some kind of acknowledgement from the chip. Now, the reset pin may not be triggered, but I certainly am at this point (sorry, I couldn’t resist): just before I had this problem, the fuses were changing for some reason. My next step, therefore, is checking the datasheet for fuse settings.

And there we have it: bit number 7 is RSTDISBL, and as the footnote lists, if it is programmed, only high-voltage serial programming will work. I recall the first fuse error message saying something about fuses being set to 0, which ends up programming the Fuse High Byte bit 7 to disable the reset pin. So, I’ve locked myself out of this chip. I’ll have to learn about high-voltage programming to see if it’s worth investing in a new thing to make that work, or whether it makes more sense to just get a new chip.

USBTiny Confirmed Working

Following up on my earlier post about the USBTiny failure to upload via AVRDude, I just did a quick test to see if I could upload a basic blink program to my ATTiny13. When I detached the cable from the ISP connector I’d sloppily soldered together, I noticed that the connections were loose – a glimmer of hope that the problem might be simple. So, I grabbed some jumper wires and hooked everything up again without the connectors. Sadly, no luck. When I wired up an ATTiny13, however, and cobbled together your average blink program, the upload worked just fine.

So, the good news is that the USBTiny itself is okay, and can still be used as an ISP programmer. Other good news is that I’m now closer to finding out the actual root of the problem. The way I see it, the options are as follows:

  • The USBTiny programmer is broken; or
  • The connections to the ATTiny84 are broken; or
  • The breadboard has faulty connections; or
  • There is a problem with the ATTiny84 itself.

My next test will have to be to put the ATTiny84 on another breadboard and try a basic blink sketch on it. That should determine whether the problem is with the ATTiny84 itself, or the other components. I sincerely hope that the blink sketch will work out, because that’ll be quite a simple problem to solve.

However, what’s far more likely a scenario, considering that I had odd error messages about the fuse settings just before I started having this issue with the chip, is that the fuses are messed up in some manner. I’ve been doing some cursory reading online, and one thing that might have happened is that the fuse bit that enables the reset pin is turned off, which means that the ISP programmer can’t initiate the programming sequence at all. Apparently, there may still be a method to rectify this, but it’s a method I don’t know (more opportunities to learn!).

Personal and Collective Responsibility

Yesterday was King’s Day in the Netherlands: a collectivity holiday on the day of the king’s birthday. Aside from the fact that it’s bizarre that we still have a monarchy (why on earth do the royal family just get our tax money? Any role they fill should just be a publicly elected offic, but anyway), it was also another bizarre display of the Dutch COVID-19 response. So very few people here follow COVID-19 measures. I regularly get questions from my colleagues along the lines of “Wow, you even wear your mask outside?” – yes, that’s right, hardly anybody here wears a mask outside.

There are so many bits of misinformation that I hear around here. Children cannot get COVID-19; masks outside are unnecessary, because the open air will spread out the virus; masks might be harmful to your lungs, and so on. Worse still are the people who recognize that COVID-19 is an actual risk but seem to lack the ethics to protect others. Someone told me: “You know, you don’t have to wear your mask here, it’s okay.” Of course I don’t have to wear a facemask. None of these regulations are full-on laws, nor do the police seem to reinforce what few measures there are. I choose to wear a facemask to protect others.

The past year has really highlighted a part of Dutch culture that I don’t appreciate: its lack of collective responsibility. When the people I speak with make light of the risk they run themselves, on the face of it that seems like personal freedom. If they don’t see much risk in getting COVID-19, then they can choose to run the risk themselves. However, even a brief analysis of the idea shows that the main problem of this virus is how easily it transmits from one person to the next. So, sure, you can take a personal risk if you want but it turns into a collective risk.

Clearly, the examples I can list are all anecdotal. Maybe I just know many people whose ethics differ from mine – a highly likely scenario. However, this is a scenario that seems to be national. Hardly any Dutch person wears masks unless they are required to do so, yet the government just will not make it mandatory except for stores. Yesterday, during King’s Day, throughout the day I saw groups of drunken partiers meet up with larger groups, and hugs were exchanged among all as they shouted happily. As of today, the government is opening up bars and shops for regular business again, despite multiple hospitals warning that their intensive care units are reaching their newly-expanded capacity once again. The government’s own crisis advisory team has advised against easing restrictions.

Some of the public discourse that right-wing parties are trying to get going is that the real problem lies with the EU distribution schemes for vaccines: it’s because the EU ends up exporting the vaccine to many countries that the Netherlands doesn’t have enough vaccines, so we’re in this situation. For one, it completely ignores the repeated misinformation that these parties spread (one of the parties even organized its own anti-mask rally), but it also ignores the clear data that multiple other countries in the EU are doing much, much better than the Netherlands. Now, data is always tricky to interpret. Some journalists or Twitter users are indeed overrepresenting how poorly the Netherlands is doing in some measures, and as well the Netherlands is improving slightly, but that sidesteps the reality of the matter: we could have been in a far better situations had citizens responded better.

This weighs heavily on my mind. There are large issues that need tackling. We need to dismantle the capitalist system, and we need to prevent climate change at all costs. However, that takes collective action where individuals engage with the large, abstract structures responsible for our suffering. It takes pretty much exactly the type of behavior it would have taken to alleviate the pressures of COVID-19. At times, I feel downtrodden by the view outside my window, and the careless disregard of so many fellow citizens out there.

Every now and then there’s that glimmer of hope, though. The people who do move aside to make room for passers-by. The people who are wearing masks wherever they go. The people who seriously talk about what to do about the virus. The people who talk about the benefits of working from home, and in what ways they’d like work to change once the pandemic is over. There’s not many of us, but I just hope there’s enough.

Setbacks and new hurdles

I’d left the pomodoro project in the freezer for quite a while. Last week, I figured I’d pick up on it again, and make some time for that hobby. It’s been challenging to pick it up again, however. KiCad, apparently, has had an update, and currently does not work on my PC. However, the error message that I get does not seem to be a common enough experience to warrant many questions about it online. It might be that it’s too recent for it to become an issue (it was a few days ago); it might be that the problem is unique to my setup; or, alternatively, it might be that the problem is really so trivial that most people have just applied some solution that I do not know.

Regardless, I figured to just work directly on the programming of the new uC, as that is a thing I can experiment with on the go without needing KiCad. Everything works fine for a few iterations as I test the LEDs by blinking them all in order, and I test various waiting functions, and so on. As I was testing out interrupt states, I started getting an odd message – for some reason, Avrdude was setting new fuses. On the next flash, it mentions that fuses have changed, and asks whether I want to reset them. Naturally, I do. However, the fuse setting issue seems to repeat, and then I can’t seem to connect at all anymore.

So, I figure to test some alternatives. Can I upload something else to the chip? Can I use the USBTiny to upload something to my first prototype? Is it the connections on the breadboard, is it the USBTiny PCB itself? What’s going on? All tests fail. So, a new challenge presents itself. I need to figure out where the problem is, followed by what the problem is, and then whether or not this is something that I can fix.