Loss of Audio Shield Rev D due to Overheating

Roy86

Member
Hi everyone,

I've got a overheating issue occuring that resulted in the loss of two Audio Shields Rev D and the issue is difficult to reproduce.

Using the teensyDuino 1.57 on a TeensyBoard 4.1 with Audio Shield Rev D using I2C to trigger the generation of the audio output via I2S, for some reason, the processor on the shield rapidly generates a significant amount of heat resulting in significant noise enducement and shield failure (not the teensy board).
It does not appear to be a consistent trigger but not entirely sure.

I rolled back to 1.56 and can't reproduce but it also lacks the I2C support to compartively reproduce the test.
I am by far not an expert here but after the loss of a second shield, I am not sure what could be the cause.

I'm not sure exactly how the shield operates and what the processor would be doing to reproduce and understand this issue.

Any thoughts would be helpful.
 
Not seen other reports of this.

How was the shield mounted? Over, or Under, or wired otherwise?

Did it indicated failure quickly, or only after some longer use?

Other connections made to the Teensy or Audio shield?
 
Good question,

The shield is mounted underneath with/without the Sparkfun I2C shield in between (I’ve isolated it from the test and it appears to not be a factor)

The increase in temp happens within 5-10s with failure occurring quickly within 20secs after if I2C power is not removed.

The only connection is the I2C cables and the 3.5mm going to a small 12v 30W amplifier.

Setup (minus 3.5mm Jack)
1.jpg

Split apart to show each part (The sparkfun board is standard, not power isolated and used to power the 3.3V of the teensy. I've also tested with direct pin I2C without the Sparkfun board and overheating still occurs.
2.jpg
 
Good info will rule out some guessing at issues.

Like good spacing so not direct heating or shorting issue ... another recent post noted that close stacking resulted in potential for contact shorting - and that was running AFAIK.

Confirms it is a Rev D shield and direct one to one pin mapping as socketed.

If not soldered with a short somewhere or given bad power it looks like a normal use of the hardware.

Not sure software could cause the issue - but if the code were provided there might be somebody that could give it a look.
 
While I can't share the software (unreleased project i'm contributing to), the odd thing is that has occured across two shields only when using I2C in slave. When using the serial pins or just USB, it hasn't occured once yet.
 
While I can't share the software (unreleased project i'm contributing to), the odd thing is that has occured across two shields only when using I2C in slave. When using the serial pins or just USB, it hasn't occured once yet.

@Roy86: Do you see the same overheating issues if you run any of the Audio Shield examples ?? This may help narrow down whether it might be a hardware vs software cause . . .

Mark J Culross
KD5RXT
 
@Roy86: Do you see the same overheating issues if you run any of the Audio Shield examples ?? This may help narrow down whether it might be a hardware vs software cause . . .

Mark J Culross
KD5RXT

No, I don't see the same issue occuring with the samples. I am realising there is something in the program written, i just can't understand what might be causing it though.

Specifically why would that chip on the shield generate so much heat from 3.3v with < 400mah.
 
If I am understanding your setup correctly, it sounds like the I2C is connected via an external cable as shown in your pic so the I2C not coming from the Teensy but rather an external device?

If that is the case, since I2C lines are powered via pullup resistors on the external device that may be creating a power sequencing issue and the chip is entering a latch-up condition powered by the I2C lines which is why disconnecting them stops the thermal runaway.
 
Sorry, I do not do much with Audio stuff. Mostly a few beeps now and then :D

So some of this descriptions are hard for me to understand. Especially since neither the hardware nor software were fully described.

So first suggestion would be to try to provide a more complete description of the hardware/software.

I understand from one of your posts, you can not post the software... But it might help if you could at least post a framework of the software that builds and maybe can reproduce the problem.

Using the teensyDuino 1.57 on a TeensyBoard 4.1 with Audio Shield Rev D using I2C to trigger the generation of the audio output via I2S, for some reason, the processor on the shield rapidly generates a significant amount of heat resulting in significant noise enducement and shield failure (not the teensy board).
It does not appear to be a consistent trigger but not entirely sure.

Some of the things I don't understand:

using I2C to trigger the generation of the audio output via I2S
I am not sure what this means? I2C is an interface.
I assume it is connected to some device? Is the device sending you encoded I2S data?
Or just something that triggers code in your app to produce I2S data?
Is the I2S data valid? Again as I don't do much with I2S, not sure what other questions to ask. But probably something,
like what frequency ...


Good question,

The shield is mounted underneath with/without the Sparkfun I2C shield in between (I’ve isolated it from the test and it appears to not be a factor)

The increase in temp happens within 5-10s with failure occurring quickly within 20secs after if I2C power is not removed.

The only connection is the I2C cables and the 3.5mm going to a small 12v 30W amplifier.

Again not sure what this means:
failure occurring quickly within 20secs after if I2C power is not removed.

What I2C power? Are you supplying external power to the Sparkfun Qwiic shield(https://www.sparkfun.com/products/17119)?
If so have you cut the jumper that connects the 3.3v from Teensy from the alternate power? Or do you simply mean you disconnect the device?

Have you measured the voltage going into this connection?

Is whatever your I2C device connected using QWIIC? If so then I assume it runs on 3.3v, if not, might it run at 5v? If so is it putting 5v on the I2C buss (PU resistors?)
If so the Teensy would not like that, and not sure about Audio shield, as it will also see the I2C pins as well.

Again sorry I know that I did not give you any real clues other than to suggest: post more details.
And check your connections and voltages.

Good luck.
 
Some of the things I don't understand:

using I2C to trigger the generation of the audio output via I2S
I am not sure what this means? I2C is an interface.
I assume it is connected to some device? Is the device sending you encoded I2S data?
Or just something that triggers code in your app to produce I2S data?
Is the I2S data valid? Again as I don't do much with I2S, not sure what other questions to ask. But probably something,
like what frequency ...
Not a problem and happy to elaborate.

I'm using an Arduino Portenta as the Master on an I2C bus with all the other devices as Slave one of which is this Teensy setup. The bus runs at 3.3V as all devices either only do 3.3V (via Qwiic connections) or use a logic converter (for the Arduino Uno).

The Portenta will issue byte commands to the Teensy via I2C to trigger preprogrammed routines to compile an audio sequence and then the master will trigger a request using more byte commands for info on the status of the program.

The Teensy Program uses the "AudioOutputI2S" to the shield for the speaker output.


Again not sure what this means:
failure occurring quickly within 20secs after if I2C power is not removed.

What I2C power? Are you supplying external power to the Sparkfun Qwiic shield(https://www.sparkfun.com/products/17119)?
If so have you cut the jumper that connects the 3.3v from Teensy from the alternate power? Or do you simply mean you disconnect the device?

Have you measured the voltage going into this connection?

Is whatever your I2C device connected using QWIIC? If so then I assume it runs on 3.3v, if not, might it run at 5v? If so is it putting 5v on the I2C buss (PU resistors?)
If so the Teensy would not like that, and not sure about Audio shield, as it will also see the I2C pins as well.
The I2C 3.3V is used to power the teensy (based on the specs of the Sparkfun shield). Basically I disconnect the I2C and kill the board to prevent temp becoming critical. I tried the Alt power route and got the same results though.


What i'm thinking is it could possibly be over-voltage 3.3v->5V (but can't see on the testers) or something causing a draw on current.

I was wondering about the impact of using Teensy as a slave while using the shield. The store indicates that "the I2C pins SDA and SCL on the Shield are used to control the chip and adjust parameters" while the "Audio data uses I2S signals". Could the commands i am using trigger this behaviour on the shield or the teensy is prevented from sending commands?
From https://www.pjrc.com/store/teensy3_audio.html
The SGTL5000 operates in "slave mode", where all its clock pins are inputs
 
@Roy86 - Thanks I sort of understand a little better, but it may be beyond my pay grade ($0.00) :D
Especially as there still is for sure not enough data to even start to try to setup a test to try to isolate it.

Hopefully someone like @Paul who understands a lot more about the Audio and Electronics will have better idea on what the issue may be. But if it were me doing this project, some of the things I might query about and/or try to do include:

a) Not sure if the I2C object (Wire) will work OK being both Master and Slave. Don't know if these devices (Portenta and Teensy) support multi-master or not... So when in doubt I would probably try to eliminate the question. That is I would probably lose the Sparkfun board and connect the two using Wire1 on Teensy (pins 16, 17)

b) Wondering how you are feeding 3.3v from Portenta to Teensy? Over the QWIIC connector? Or using the ALT power connector on the Sparkfun board? I am not sure how much current the qwiic connectors are supposed to carry? I am guessing you are trying it using the QWIIC ones as I don't see anything in your pictures suggesting a connection to the two external power pins.

b1) If using external pins, not sure how well the Audio system works if you drop the voltage through the diode on the Sparkfun board.

c) I would try to eliminate passing 3.3v between the two boards. That is I would try to supply 5v to the Teensy, and have a common ground. And not have power going from QWIIC pin to either board. Just the two signals and GND and see if the problem persists.

If it still looks like even with hardware like this, the problem persists, I would then I would suspect something more software wise... So would probably instrument the code to know what events happened before and during when the the device starts to overheat and save that away along with appropriate data, such that hopefully you could then boil it down to a smaller test case sketch and maybe audio files that reproduce the issue. And then hopefully someone could help debug.

Sorry I know I am just throwing darts.
 
No this is very helpful. I haven't tried the other I2C ports so will test them out too as well as your other suggestions.

For 2), the Portenta I2C through the breakout board is 3.3v and is using Pin->Qwiic connection. I tried the ALT power earlier as well but still had the same result.

More testing to come :D
 
Was going to note the two masters issue. To talk to the Audio card the Teensy is Master - then turns around being Slave to the other Master?

That shouldn't happen on the same i2c bus pins.
 
Back
Top