Loud samples crashing custom teensy w/ audio

Y

yeahtuna

Well-known member
I've been spending a day trying to figure out why some loud bass drum samples I was playing back were crashing my test device. At first I thought it was a memory management issue, but it's turns out to likely be a power issue with my desing using the SGTL5000 when powering my AKG 240 headphones (55 ohm drivers). It I turn down the volume or unplug the headphones, the device is stable. Are there any specific layout considerations that I need to account for when powering these kinds of headphones?

I'm attaching a pic of my schematic and layout. I'm using the AP7313-18SAG-7 (1.8V) regulator for the SGTL5000.

1761198239774.png
1761198278979.png
 
I fixed the issue by using a much larger value capacitor on the output of my device's main 3.3V regulator. I was using 4.7 uF and I moved up to 22 uF. Probaby would also be a good idea to switch from an 0603 package to an 0805.
 
Maybe it's my eye-sight, but I don't see how PAD is connected to Ground.
The 4.7uF capacitor on 1V8 rail does not have a connection to Ground.
I see labels for GND, but no connections.

Also, is SGTL5000 soldered to the PAD?
 
There's a copper GND pour on the top and bottom layers of the boar, I just didn't show it.. It's definitely connected.
 
Okay. Thanks for clarifying.

BTW, what's the part number you ended up using for FB1 ?
 
Interesting timing! This week, I was helping diagnose code on a custom Teensy with SDRAM (I2S audio player software) that was experiencing random crashes. Whilst making code changes to attempt to diagnose / resolve, the test plays a song too loudly and got annoying repeatedly playing it, and without a hardware volume control on the device, I added code to adjust the sample data to reduce the volume 90% - and it stopped crashing. I first thought it might be due to the additional code running in the ISR, altering timing, creating an implicit memory barrier etc, but after exhausting that avenue to no avail, I just removed the volume code and unplugged the speaker - and that also resolved the crashing :) So also then suspected a power issue, especially with SDRAM used for heap and the audio buffers potentially being more sensitive to brownouts. Still working on this, as there may also be additional software issues, but good to see that the theory I had can actually be a valid one!
 
beermat said:
This week, I was helping diagnose code on a custom Teensy with SDRAM (I2S audio player software) that was experiencing random crashes.
Click to expand...
If that's the board that dogbone06 made with the industrial grade IMXRT1062, are you using the modified clock speed setup code that applies higher voltage settings? It's prone to brownouts without it.
 
jmarsh said:
If that's the board that dogbone06 made with the industrial grade IMXRT1062, are you using the modified clock speed setup code that applies higher voltage settings? It's prone to brownouts without it.
Click to expand...
That's a good question. We're running at 528MHz. The original code owner has a board from dogbone06 that was used in the forums, I'm using a later revision with several hardware changes. I had modified my local clockspeed.c to increase the voltage if clockspeed was greater than 528MHz (to 1.3v), but didn't consider increasing the default. Will experiment.
 
You must log in or register to reply here.
Back
Top