Arduino and Wire.endTransmission()

[m12lrpv]

But since any I2C device going down can take down the whole I2C bus, hanging would therefore depend on every I2C device/code not going crazy and hang the system.

I can imagine an MCU program merely queue up bytes until the I2C bus is available, and it keep queuing, and queuing, until memory overwrite somewhere.

I've generally found the atmels with the arduino wire library to be quite robust except for where there are interrupts involved (because their I2C relies on interrupts to work). It certainly doesn't let you overflow the buffer.

Still, you can get a slave device that clock stretches or just a badly wired signal lines which could slow things down. Haven't encountered one yet but there are ways around it when I do.

[tiborsimon]

If you communicate a 3.3V device with a 5V Arduino make sure you turn off the pullup resistors. These are turned on by default and pull up the lines to 5V. That's why you don't need external pullup resistors when playing with the Arduino in normal cases.

Turn off the internal pullups (digitalWrite(A4,LOW);digitalWrite(A5,LOW); on UNO R3) and pull up the SDA and SCL lines externally to 3.3V otherwise you can damage the 3.3V device. I killed several accelerometers before I realized this issue

[Dajgoro]

I tried using the I2C library, on 3.3V and 5V (without any sensors) and it is the same thing, pulls the signal for a cycle low, and restarts. I even tried without any other stuff, just a simple write loop, no serial link, I just probed the I2C lines with the scope.

[Dajgoro]

Ha!?

I tried software bitbanging, and it works, but odd thing, if I use the pins 3 and 4 as outputs it crashes in the same way as the wire library, but on 6 and 7 it works. Ha? why setting a pin low causes the mcu to crash? What is going on here?

Edit: Pulling down a 2k resistor causes the crash!

Edit: I don't want to think about it!

NOoooooooooooo

Adding extra bypass caps doesn't help.

Edit: I used 8k resistors, and it works now, everything works!

Why a ~1mA current causes the mcu to restart?

[m12lrpv]

Why a ~1mA current causes the mcu to restart?

It doesn't, but something in your circuit does.

[Dajgoro]

Why a ~1mA current causes the mcu to restart?

It doesn't, but something in your circuit does.

But what could that be, the circuit has only those extra two pullups added to it.
It is the same thing on 3.3V and 5V. There are no extra devices/circuits connected to the mcu.

[m12lrpv]

It doesn't, but something in your circuit does.

But what could that be...

Hard to say given that you won't show your circuit.

On the plus side you've successfully confirmed that I2C is not the problem since you've been able to reproduce the issue while simply using the GPIO pins.

[Dajgoro]

It doesn't, but something in your circuit does.

But what could that be...

Hard to say given that you won't show your circuit.

On the plus side you've successfully confirmed that I2C is not the problem since you've been able to reproduce the issue while simply using the GPIO pins.

It all works now, but the mystery remains.

As I said, there is not much to show, it is just an atmega328 on a separate pcb with a 3.3v reg, with the rst, tx, rx pins tied to the original arduino uno board.
Well, once I finished poking with the sw, I separated it, so now I have a stand alone device.

[m12lrpv]

... with the rst, tx, rx pins tied to the original arduino uno board.

Based on the information provided the original arduino uno board would be 5 volt which means you're putting 5 volt into your reset pin as well as your RX and TX pins.

That will cause problems. Wouldn't be surprised if the chip was damaged too.

[Dajgoro]

Wouldn't that also mean that sending a signal to an unpowered mcu would also damage it?

[Rick Law]

I can imagine an MCU program merely queue up bytes until the I2C bus is available, and it keep queuing, and queuing, until memory overwrite somewhere.

That's why you should have timeouts and deal with the errors (such as SDA or SCL stuck low) instead of assuming every transaction will work.

I guess I did not express my point.  I was hypothesizing the reason for "I don't understand why it would hang."

Since I2C communicates between devices, one may not control all the codes running in all the devices.  You can program the cleanest program in the world, but the I2C bus requires that all the devices are playing good or at least good enough.

So, a well written program hangs not because of the codes not written right, but the system itself not feeling well - such as the MCU may be lacking oxygen (power) because the LCD that normally draw 30mA starting to draw 100mA and sucked all the oxygen in the room.  The LCD draws 100mA because it's code got stuck somewhere due to another device hanging the I2C bus...  possibility is endless.

Come to think of it, it may not even be "quick and dirty."  Given the limited space in firmware, it may well be not having the space to implement defensive programming.  I just took out a chuck of code that tests the selected options against conflict - precisely because I am running out of RAM.  But my stuff is just for fun, so no airplane is at risk of going off the runway killing hundreds...

[m12lrpv]

Wouldn't that also mean that sending a signal to an unpowered mcu would also damage it?

Possibly. In the end it comes down to how much current is running the wrong way through the MCU and for how long.

[Dajgoro]

Wouldn't that also mean that sending a signal to an unpowered mcu would also damage it?

Possibly. In the end it comes down to how much current is running the wrong way through the MCU and for how long.

what about a mcu that usually operates at 5V, but when unpowered there is still a serial tx signal left high on a pin?

[m12lrpv]

what about a mcu that usually operates at 5V, but when unpowered there is still a serial tx signal left high on a pin?

Same as before.

In the end it comes down to how much current is running the wrong way through the MCU and for how long.

It will also depend on the input off state of the TX pin. If in the off state it goes high impedance then it will limit the current flow. If in the off state it's high impedance with a pullup active then current will feed through that pullup into the rest of the device.

For example many devices can stand over voltage on the wrong pins if you have large resistors limiting the current flow to a safe level. It's how the ebay sellers can get away with claiming 3.3v SD card shields are usable at 5v because they put 10k resistors on them that keeps the current low enough that it won't burn anything out.

If you can't maintain supply current you will find it sucking current in through your other pins depending on their configuration hence bypass caps can be critical too. It's all about different of potential.

Probably a good reason to leave things like brownout detection on albeit at a lower level.

After blowing up my first Arduino by putting voltage through it the wrong way  I tend to pay more attention to the state of the circuit I'm putting, it in particularly now that most of my projects are now on standalone circuits and not on Arduino boards.