Smoked a chip. Trying to narrow possibilities. SERIAL_TX_ONLY? Pull down resistors? Library?

[unhinged-engineer]

FTR, most of what I'm using is something that worked flawlessly on Arduino Nano. Both the hardware configuration and the code. Trying to figure out what went wrong.

Programmer is an adafruit FTDI friend, FT232RL, running at 3.3V, and a schottky diode from RX to TX. Dev board is a LeoNerd ATtiny1616. The only connections from the FT232 to the tiny are UPDI and Gnd. Vcc is NOT connected. Board is running off of a bench supply, running at 2.8V

I got the "hello world" code to compile and upload successfully (optimized for size, for now), and then moved on to the next step. When I uploaded the new code (I can't remember if I pushed a button or not), the bench power supply jumped from ~4-6mA, up to 450mA, at 2.8V. I knew something was wrong, but I didn't know WHAT. When I connected serial, the chip was still outputting, but the data was slightly corrupted. I tried uploading the old code. No Joy. Tried burning bootloader. No communication. When I put serial back on, the corruption was getting worse (not shocking). The chip is functionally dead, and I'm still waiting on the spares that I ordered. Trying to figure out what went wrong, in the mean time. Here's the code I uploaded.

/*
anti-cant code for ATtiny 1616, with ST LIS2HH12 accelerometer
UPDI on PA0 (stock)
SPI and USART moved to alternate pin sets to allow for PB to be used in it's entirety, for digital control of yellow LEDs
  SPI.swap(1);
    Should only need PC0-PC2, leaving PC3 available for digital use
  Serial.swap(1);
    configure for simplex, TX-only, using only PA1
      leaving
        PA2 open for analog in or interrupt (Button, interrupt)
        PA3 open for analog in or PWM out (battery check, analog?)
        PA4 open for analog in or PWM out (Yellow LEDs, PWM)
Dev board has reset switch (SPST-NO, to ground, through 180 ohm) on PA0.
Dev board has LED on PA7, through 2.2k ohm, to ground. Do not use for I/O, until debugged.

Max baud rate @10MHz clock:
  512kbps with UX2 (U2X?) off
  921.6kbps or 1Mbps with UX2 on
*/

#include <SPI.h>     //SPI comm is critical
#include <ansi.h>    //ansi escape code library, for displaying information on a serial window
#include <EwmaT.h>   //Exponential Weighted Moving Average (integer math) library
#include <button.h>  //extremely simple button debounce library. github.com/e-tinkers/button *DO NOT USE AS-IS. MUST BE AMENDED TO ACTUALLY **WORK** CORRECTLY*
//#include <EEPROM.h>     //EEPROM read/write control, for storing "zero" to memory
#include <avr/sleep.h>  //sleep library, to save power when not on

ANSI ansi(&Serial);

Button btn1;
Button btn2;
bool B1_state = false;
bool B2_state = false;
bool one_held = false;
bool two_held = false;

void setup() {
  SPI.swap(1);
  Serial.swap(1);
  Serial.begin(512000, SERIAL_8N1 | SERIAL_HALF_DUPLEX | SERIAL_TX_ONLY);

  //initialize buttons
  btn1.begin(PIN_PA6);  //identifying pins for buttons, and creating the "arrays" for them
  btn2.begin(PIN_PA2);
}

void loop() {
  if (button_listen()) {
    digitalWrite(PIN_PA7, true);
  } else digitalWrite(PIN_PA7, false);
  printyprinty();
}

void printyprinty() {
  static unsigned long next_print_time = 0;
  static const unsigned long print_delay = 1000;
  if (millis() >= next_print_time) {
    Serial.print("hello_world ");
    next_print_time = (millis() + print_delay);
  }
}

//check for button activity

bool button_listen() {
  B1_state = btn1.debounce();
  B2_state = btn2.debounce();
  if (B1_state || B2_state) {
    return true;
  } else {
    return false;
  }
}

When using USART, on a Tiny1616, I'm wanting to run serial as TX only, to save pins. Do I need to call "SERIAL_HALF_DUPLEX", or can I call just "SERIAL_TX_ONLY", and still use the pin that USED to be RX, for an input? I'm wanting to attach a button to PA2, for the interrupt function (also putting a button on PA6, for the same purpose). The buttons are SPST-NO, connected straight to ground. On arduino, this worked fine, once I debugged the button.h library. Here's the amended library.

#ifndef button_h
#define button_h

#include "Arduino.h"

class Button
{
  private:
    uint8_t btn;
    uint16_t state;
	bool metastate;
  public:
    void begin(uint8_t button) {
      btn = button;
      state = 0;
	  metastate = false;
      pinMode(btn, INPUT_PULLUP);
    }
    bool debounce() {
      state = (state<<1) | digitalRead(btn) | 0xfe00;
	  if (state == 0xffff){
		metastate = false;
	  } 
	  if (state == 0xfe00){
		metastate = true;
	  }
	  return (metastate);
    }
};
#endif

Currently, all pins other than PA0, PA1 (serial TX), PA2 (button, to ground), PA6 (same as PA2), and PA7 (LED to ground, through 2.2k) are floating.

Any ideas what I did to kill the poor chip?

[SpenceKonde]

Whaaatzeeefawwwkkkkkk

I do not know what you did to kill the chip,. If it was triggered by software, in involved external hardware doing something unholy. Unless you somehow managed to find a literal halt and catch fire function. 450ma and smoke says to me "voltages outside the supply rails are involved". Was there something that was

As for serial configuration, you want SERIAL_TX_ONLY. You don't want half duplex. You said you want to transmit only. There's nothing duplex about it - it only lets the signal go in one direction. Half duplex lets data go in both directions but not at the same time and full duplex lets data both both directions at the same time

I will clarify that Serial TX only should not be combined with SERIAL_HALF_DUPLEX or whatever I named the option that controls the LBME bit.

TX only will leave the receiver off. The pin can be used for other purposes.
RX only will leave the transmitter off. The pin can be used for other functions.
Half Duplex sets ODME and LBME.
ODME causes the serial port to act as open drain (ie, it won't drive the pin high, only low.
LBME disconnects the RX pin (it can then be used for other purposes), and connects it to the TX pin instead.

So that's how you get half duplex - with ODME you never drive the pin high, an just have the internal pullups on on both sides, and maybe external pullups depending on speed, wirelength and other factors, and multiple devices can each be connected to the same lwire and drive it low or leave it be. And loopback mode, while one effect is that you "receive" every character you transmit, it also means that if the pin is in open drain mode and something else is driving it low in a pattern consistent with serial, you'll receive that too.

When in half-duplex (ODME + LBME)
The implementation in megaTinyCore turns off the receive interrupt while transmitting, and then in the transmit complete ISR, empties the incoming data buffer (which will still have a few characters we sent), turns receive interrupt back on and turns OFF transmit complete interrupt but does NOT clear the flag

In all cases, When something it printed or written to serial, at that point only do we clear the TXC flag - and if we're in half duplex mode, we also reenable the TXC interrupt.

SERIAL_TX_ONLY and HALF_DUPLEX (specifically the LBME part) make no sense. because. It... reroutes the TX signal to RX, but it falls on deaf ears because receive is turned off. so why bother?) And if you want ODME, just ask for that.

For transmitting only, SERIAL_TX_ONLY should be all you need.

[unhinged-engineer]

Whaaatzeeefawwwkkkkkk

As you may have noticed, I am exceptionally good at finding ways for things to go wrong. I'm a mechanical engineer, not a programmer, so this comes as no surprise to anyone. I'm doing this for work, because no one else can do what the boss asked for.

Thank you for the insight on SERIAL_TX_ONLY. That was something I couldn't quite figure out from documentation. I was looking for "simplex" but couldn't find it.

Either way, PA2 should have been available for other purposes, as far as the mcu was concerned, and the library in question SHOULD have triggered the pullup resistor, which the button would have pulled down, but shouldn't have shorted anything.

This is going to be a fun debugging run. I should probably buy a large handful of chips, and get used to swapping them out.

[MX682X]

when the chip started smoking, was it still connected to the FTDI chip?
I have the feeling that the higher Voltage of the FTDI (3.3V - 2.8V) might have lead to the problem. It seems like an ESD diode on a pin shorted, as the CPU was still running.
Sure, the datasheet says the pin can handle up to 13V for a UPDI reset, but it was desgned for pulses, not for a continous load.
There was no mention of a resistor on the UPDI line. Do you have one between the Serial adapter and the Tiny?

[unhinged-engineer]

Full disclosure: there was no physical smoke. I say "I smoked it" to mean that it doesn't work at all, now.

I measured the FTDI at 3.38V, which worried me (I thought the accelerometer chip was a max of 3.3V, but it's actually 3.6V), so I did not connect VCC from the FTDI to the breadboard that has the mcu on it. The schottky diode should isolate the mcu from the ftdi TX voltage, if I'm looking at it correctly. That said, there's a caveat.

I have two headers for the FTDI, on a separate breadboard. One has a schottky diode, the other does not. I was using the one with the schottky to do UPDI programming, and the one without to get serial data. Both headers only have GND and RX pins connected to mcu (diode is from rx, to tx, so power output shouldn't be possible). The diode header has RX connected to PA0 on the mcu, for UPDI. The non-diode header has RX connected to PA1 for serial data from mcu. I don't think I fucked up, but if I hit "upload via programmer" while the FTDI was connected to the non-diode header, there shouldn't be any voltage applied to the RX pin that WOULDN'T have been there, from the diode header. Right?

As far as a resistor: I THOUGHT the FTDI board had a 470 ohm resistor on the TX line. Looking again, it looks like it's only a 22 ohm (470 is on the LEDs) on the TX line, and nothing on the RX line. Neither pin (PA0 or PA1) on the MCU has any resistor.

[MX682X]

My best guess would be - try to have an extra resistor in series, just to be sure. can't fry anything in the worst case with a small enough current.
Maybe this might help aswell - https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

[unhinged-engineer]

I've added a 510Ω in series to both header positions. We'll see if that helps, when the new chips get here.

regarding the jtag2updi document: I had read it, and since I thought there was a 470Ω resistor on the line, I thought it was fine.

[unhinged-engineer]

I'm still not sure what the cause was, but I added the resistors, and haven't had an issue, since. We'll call it that, for now. Thank you all!