Noise Issue with Teensy 4.1, Audio Shield, and PAM8403 Amplifier

@PaulStoffregen Paul what is a good turn on delay, and/or ramp for the 5V line feeding peripherals?

I am contemplating adding a load switch, but I want to think about it a little more.

BTW, any suggestions?
 
In my humble opinion, I think 2x 22uF won't hurt USB powering devices. I have often added capacitors to limit noise up to 100uF, without troubles for now. Some circuits inject so much noise in power rails, like little class D amps (pam8403), oled displays, TM1637 7-segments displays... even with well designed PCBs, I always struggle with noise.
Emmanuel
 
DrM said:
Paul what is a good turn on delay, and/or ramp for the 5V line feeding peripherals?
Click to expand...

I'm afraid I don't quite understand your question.

If you didn't read page 177 yet (direct link to the PDF back in msg #21) please do so. It's only 1 page and gives some really good discussion of important issues to keep in mind. I'm really not eager to spend a lot of time when it's so well explained in the USB spec.

Teensy already has a hardware power up sequence documented on the T4 bootloader chip page and a software startup sequence documented on the startup hooks page. Those together are the default turn on delay. If you haven't read those, please do so, because again I'm not eager to repeat all the info.

If those don't answer your question, maybe explain a bit more context so I can understand what you're really trying to ask.
 
PaulStoffregen said:
I'm afraid I don't quite understand your question.

If you didn't read page 177 yet ...

hardware power up sequence documented ...

If those don't answer your question, maybe explain a bit more context so I can understand what you're really trying to ask.
Click to expand...

I read the USB page. I read the Teensy power-up sequence, and the startup hooks page (a long time ago and again just now)

So far what I came up with to manage the in-rush current for the peripherals (and the filter), might be to use a load switch with a long ramp.

As such, it comes down to setting the timing and the ramp for the load switch. Controlling it from a digital i/o pin of course might make that a little simpler.

But then as I look at the datasheets, there is a new problem; sudden power loss can leave the load at higher voltage than the input and drive current back through the swtich. So there are still issues to be worked out.

Suggestions are welcome of course.
 
p/s a further thought. does it seem plausible that the C-L-C filter configuration could draw down the usb to the point of delaying the teensy turn on?

Anyway, Paul, it seems like you probably have a lot of experience with this sort of thing in working out the power up for the teensy. Any ideas or recommendations how to go about this?
 
Maybe it will provide some inspiration. In one of my projects i've used an adjustable power distribution switch (BL2555) + comparator to limit the inrush current while charging a 1000uF cap:
github.com

GitHub - hexeguitar/4WD_UART: CH344Q based quad isolated USB-UART interface with ESP programmer.

CH344Q based quad isolated USB-UART interface with ESP programmer. - hexeguitar/4WD_UART
github.com github.com

BL2555 internally blocks the reverse current, discharges the output capacitor during the shutdown, plus - it can be used as main power switch.
The inrush current is limited to the about 90mA. The voltage on the main decoupling capacitor is compared with the VBUS and once these two are close, the current limit is increased to full capacity.
 
@PaulStoffregen

Here is an appnote that perhaps has an answer for USB power management for peripherals.

Using Dual Current Limited TPS2140/41/50/51 for USB and Portable Applications

In this usage "Dual" seems to mean that it has both 5V and 3.3V outputs. It is designed to handle in-rush and power to meet USB 1.0 and 2.0 specifications.

There is one thing to be careful about though:

Analog-digital chips of various sorts, with an SPI interface, often have separate power for the analog and digital sections. The digital power pin sets the logic level for the SPI interface.

And with the above power management chp, we now have two devices connected to each other by SPI, and they are getting powered up separately and quite possibly one before the other.

On the peripheral side it is typical to see a maximum rating for digital input voltage written as DVDD+0.3V Here is an example, the ADS8881.

So, I think the simple solution is that we have to use the Teensy's 3.3V for the peripheral's DVDD.

Otherwise we might ask: What is the power up state of the digital I/O pins on the Teensy? And, would the Teensy tolerate3.3V on a digital i/o pin while or before it is powering up? But anyway, I think the above is much simpler and more reliable.

So that's it. Peripheral's SPI interface powered by the Teensy's LDO and otherwise 3.3V and 5V for peripherals from the TPS2140/41/50/51
 
To avoid inrush problems, i use the 5V from the usbHost on the Teensy4.1.
I wait half a second before activating the usbHost.
I use it like a controllable power rail. (Which is possible on the 4.1 but i don’t think it’s possible on the 4.0)

I use a quite similar power rail filter (100uF 5uH 100uF) to power my audio dacs.
They are not contaminated by power railnoise (coming from 2”42 oled displays in my case).
 
Last edited:
@SmashedTransistors Ahhh, those clever americans! The USB host on the T4.1 is powered through a TPD3S014 (a current limit switch) and the enable is controlled by the MCU. It does everything you need, over and reverse current, and discharge. Brilliant.

(Aside, what is the minumum code to turn the usb host on and off?)

The drawback is that the TPD3S014 is powered after the 0.5A fuse (see schematic below). So total draw is 0.5A including the T4.1 (100mA ?) and whatever is powered by its 3.3V LDO (a TLV75733P, 1A). I think that leaves 400mA for all of the peripherals (5V and 3.3V) together. (*)

But, there is still the nagging question about what happens wrt digital i/o connections when one thing or the other is powered up first.

@PaulStoffregen , help, please?

1) On quick perousal of the Processor Reference Manual, it looks like the GPIO pins are initially tri-stated. Is that correct?

2) Does that change during the power up sequence?

3) What is the state of the digital i/o pins when a user sketch enters setup()?

Apologies if you have documented this somewhere, I have not found it.

Thank you


For those who don't have the schematic at their finger tips, here it is. Notice the TPD3S014, it runs from the USB after the fuse and filter. So, max is still 500mA including the MCU and whatever else is driven from the 3.3V LDO


1739743359502.png




(*) If someone needs more that 400mA, perhas the TPS214/5x (0.6A) or TPS25221 (adjustable up to 2.7A) might work, though I have no idea what vin on the t4.1 could accomodate).
 
DrM said:
(Aside, what is the minumum code to turn the usb host on and off?)
Click to expand...
Assuming you mean only powering the VHST pin and not bringing up the entire USB host stack...
The TPD3S014 is controlled by a GPIO (EMC_40) so all you have to do is set it to output mode and turn it on. Unfortunately it has no defined pin number in Teensyduino so that has to be done manually rather than using pinMode()/digitalWrite():
Code: 
    IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_40 = 5; // set mux for EMC_40 to GPIO
    IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_40 = 0x0008; // slow speed, weak 150 ohm drive
    GPIO8_GDIR |= 1<<26;  // set the pin to OUTPUT mode
    GPIO8_DR_SET = 1<<26; // set pin level HIGH
 
@jmarsh Thank you, perfect. That is indeed exactly what I was looking for. But now that I see Paul's library, some other uses come to mind, For example, a temperature control loop with a thermistor and a TEC powered by a programmable power supply. And, I've seen thin film deposition chambers run by arduinos and lab jacks (miraculously, one might suppose). The teensy 4.1 could do that so much better.
 
Regarding questions about the pins, the 100K resistor (R8) is meant to keep the USB host power off until software explicitly turns it on.

Sorry, I don't have time to write a lengthy explanation about the pins, but you can find full documentation in the reference manual and datasheet if you really want to dive into the deeper details.
 
@PaulStoffregen

Paul, does your boot prom configure or put the dio pins in any particular state?

If we had the source code for the boot prom we could check this ourselves. It is a very important thing to know.
 
Speaking strictly for myself (not intending to answer for Paul), do you realize how totally unrealistic (can't think of a better adjective at the moment . . . not enough coffee this morning) that your request really is ?? Paul's boot mechanism is integral to the technical process that takes a generic IMXRT1060 processor & turns it specifically into a Teensy. Taking care to protect the entirety of that intellectual property is key to keeping offshore thieves from mass producing & under-cutting his original product(s). Try putting yourself in Paul's shoes & imagine if you would be releasing the kind of info that you are requesting, & thus digging the grave of your company ??

Paul can & will & does answer most any technical questions that anyone may post (as long as they aren't within any NDA space), but I am fairly confident that we can be certain that he will not endanger the future of the entire company by posting boot code. Absolutely no insult intended, but hopefully you can consider exactly what you are asking & maybe you will realize how unreasonable your request actually is.

Mark J Culross
KD5RXT
 
Paul doesn't have to post the code to answer the question. Does the bootloader configure the pins? Or does it leave them tri-stated? Or, some of them?

It is certainly something that we need to know if we are designing a power-up involving the Teensy and another board or circuits that are connected to it.
 
I'm dealing with a similar problem.

I've got a pretty decent signal coming off a 4.1teensy compatible audio board (I think rev D), and going into a pair of SONY headphones and being subjectively judged by my simple brain. But it's not ideal for me to be listening to the audio output from the audio adapter board - I'd really like to amplify the LINE-OUT (only using 1 channel) so I don't need to use headphones.

I want to get as clean as possible audio source from an amateur radio speaker out, perhaps dropped to line-level using a resistor divider (basically a divide by 10) often used by people for doing similar. The capacitor on the line-in and line-out remove the DC.

Connected to the daughter board is also an I2C rotary encoder, and and I2C 16x2 LCD controlled by a PCF8574 adapter. Maybe in some manner, I am to use another I2C I/O point for this purpose?

Now then, should I use audio transformers on the line input and output signals to perform isolation? While that sounds (ha ha, this must happen a lot when describing things) like a plan, the transformers are likely to limit the bandwidth of the source and output signals to from the audio board which I'd like to avoid. If I were to do so, would I use 600ohm/600ohm audio transformers?

I like DrM's post for filtering the input 5VDC. Should the 3.3V presently powering the encoder (from the teensy) be filtered in any way, or should I use an external source?

I'd like to run the resultant line-out to a simple and inexpensive LM386 based amp if possible, and don't know what constitutes "best practices" overall with the teensy/audio board combo for projects.

I general guide and some example solutions compiled in one spot would be helpful if it exists.
 
The 3.3V line is produced by an LDO, a TLV75733P

The design process normally would be that you formulate a noise budget at various points in your circuit, check the data sheet for the noise level from the LDO, and check the power supply rejection ratio (PSRR) for your opamp. The PSRR applied to your power supply noise has to be lower than your noise budget at each point.(*)

Notice that the LDO also has a PSRR. See the schematic below. The LDO shares its input with the USBn_VBUS. The output of the LDO feeds a few circuits of the Teensy 4.1 that are involved in digital signaling or have clocks, and it goes directly to the 3.3V pin, all with no bypass caps.

I usually don't power analog circuits from the 3.3V. Where I do use it, I put a 10uF near the 3.3V pin from the Teensy and sprinkle footprints for more of them around the power plane. And of course, be sure to follow the datasheets for bypass caps on the power pins for your circuit design. And remember that bypass caps should be as close as you can manage to the power supply pins.

You could try looking at the 3.3V with a scope, but it might hard to see the noise unless it is already too big.

Finally, if you have a low pass filter, that might help you, providing you are not clipping before the filter has a chance to cleanup the signal.

(*) P/S There is more that goes into noise, c.f. input noise density, etc., contributions from other components, etc., layout practices and board materials in some cases, etc. Here we're just talking about noise from power.


1739812755090.png
 
P.P.S. re the lm386, etc, I dont want to say "do this" or that, but nowadays i almost always use spice, and include noise and response analyses, before I build the circuit
 
@
DrM said:
P.P.S. re the lm386, etc, I dont want to say "do this" or that, but nowadays i almost always use spice, and include noise and response analyses, before I build the circuit
Click to expand...
Well, I definitely appreciate the response. On the 4.1 board, is that connection between VUSB and VIN (at those pads) common to one another, unless I mechanically cut it? So, then I need to cut that connection between the pads if I want to power my project from some other source than the USB connection (if I want to continue to use the USB port for programming or perhaps handling audio in/out to the USB host (ex: PC)), right?

OK, modelling things with SPICE or PSPICE is not something I've done before, and to be honest, I was looking for a collection of "I did this or that to limit the noise in my project"). And I realize we are strictly conversing about PS noise sources, correct?

Then, in general, I know that as far as construction techniques are concerned, long-wires used with breadboarding a MPU and other circuitry involving audio is problematic, but like SPICE and PSPICE, I don't possess true expertise. I am however learning from the posting and schematics of others.

And so, naively, other items like should the audio adapter board be mated to the Teensy4.1 control board on-top, or on-bottom of the Teensy or from a noise perspective, does it matter? That is something I would like to know.

I'd also like to know, again I beg forgiveness of my ignorance, if using an external supply (and not V-USB), can I place as much capacitance as I want on Vin without messing up the boot up of the Teensy controller board?
 
It is hard to generalize, but for the circuits that I build, I don't think I would stack above or below an MCU board, unless there was really very good shielding and very good power filtering.

The best thing is make a PCB with a footprint for the Teensy or sockets for it, and whatever other components that you want. You can share ground, but separate the power planes from the teensy and use lots of bypass caps.

Two things that I feel are super important, spice and an oscilloscope.

Aside, it may be that I have been getting away with so much bypass capacitance because I use very powered hubs. When I shop for them I look for at least 1A or 5W per port.
 
DrM said:
Paul doesn't have to post the code to answer the question. Does the bootloader configure the pins? Or does it leave them tri-stated? Or, some of them?

It is certainly something that we need to know if we are designing a power-up involving the Teensy and another board or circuits that are connected to it.
Click to expand...
It doesn't. The Teensy "bootloader" (the MKL02 chip, to be clear) isn't responsible for running any code at all during the regular boot-up sequence - it only handles power sequencing. It takes control of the CPU (via jtag) only when the program button is pressed or the CPU executes a breakpoint instruction.
 
Great, thank you. Perfect.

In other words the pins are in their default state when the "sketch" is entered. I'll look again, my first impression was that they are tri-stated. In other words, a peripheral that powers up ahead of the Teensy and asserts a high on one of its digital i/o pins is not going to hurt it. Yes?
 
DrM said:
Great, thank you. Perfect.

In other words the pins are in their default state when the "sketch" is entered. I'll look again, my first impression was that they are tri-stated. In other words, a peripheral that powers up ahead of the Teensy and asserts a high on one of its digital i/o pins is not going to hurt it. Yes?
Click to expand...
Not necessarily.
The very first thing that runs on startup is the NXP ROM which is built-in to the MCU. The methods that it tries to use to load code are determined by the fuses. I'm not sure how all those fuses are set on a regular Teensy, but they're different for the lockable models which causes the ROM to drive some UART pins (and wait for an upload if it thinks something is connected).
 
The Teensy4x Pins mux shows UART1 TX, RX as pins 24 and 25. So that would seem to explain what is reported in the thread referenced by @h4yn0nnym0u5e

It is easy enough to avoid those if that is all there is.

Again, the state of the pins from power up through boot should be documented. It becomes impossible, or at least unnecessarily awkward, to build stuff around the teensy in any sort of professional way without that.
 
You must log in or register to reply here.
Back
Top