LDO problem

[hebalazs]

Hello, this is the first time I am using this project. I have some pieces of decoders. For programming, I use another open-source project (DCC-EX), and some of my decoders have died (RP2040 has a short circuit inside) due to the incorrect operation of the LDO. I measured the LDO voltage and observed a 7V peak during power-on. Currently, I have replaced the LDOs with MCP1799T-3302H/TT. It has the same package, and it has thermal and current protections. Now it seems the decoder is working properly. Have you experienced similar problems?

[gab-k]

So the problem only occured with the PJ75AL33SA? I have never had such an issue but I will try to measure it myself in the coming days. What track voltage are u using?

Admittedly, the LDO is also a weak point in the design as it is subject to very high thermal loads, especially at high track voltages, the power loss is not insignificant. I am currently working on a revised design which is improved in this respect, among others.

[hebalazs]

Yes, it is occured with the PJ75AL33SA and the track voltage was 14V.

[gab-k]

Measured this on one of my decoders, screenshot is attached, I will admit this isn't ideal either but nowhere near as bad as yours. I don't really know what causes your 7 V peak, what capacitance are you using at the LDO output?

[hebalazs]

Sorry for the late response. I use a 10uF capacitor on the output of the LDO. I noticed that in your case, the ramp-up time is 1500 microseconds, while in my case, it is about 200 microseconds. Another difference is that in my case, the track signal has a lot of noise so maybe this causes the problem with the LDO. Perhaps the control loop inside the LDO cannot handle this noise.

[Space-Farmer]

Hello together, I made similar observations:
Environment:
Train BR213 on prog track of DCC-ex with LM298 H-Bridge, controlled by JMRI:

Blue 3V3
Red: TrackA
(68µF between V+ and GND)

Blue 3V3
Red: TrackA
(68µF between V+ and GND)
(100µF between V+ and GND)

Environment:
Directly wired with prog track output of DCC-ex with LM298 H-Bridge, no add C:

Red v+
Blue 3v3

Red track A
Blue 3v3

Blue 3v3

Up to my experience it seems like that the LDO is from starting point in a over current condition, which effects the error amplifier to increase the voltage, unfortunately the assembled LDO did not recover that fast once the typical voltage is reached. One important point for having this overshoot is the dU/dt of the LDOs input voltage, @gab-k could you reperform your measurement with showing your rising edge of Track A/B? That maybe explains the different behavior of our circuits.

I saw that overshoot behavior also in some of my past projects (not that high only ~500mV) with other LDOs (also America or Europe origins). Only way to get rid of that behavior was to introduce an LDO with soft start functionality.

Maybe for this cicuit it could be an idea to introduce a series resistor or a diode to save thermal stress on LDO side and change the VIN behavior. What is your opinion on that?

If you are currently working on a redesign I would highly appreciate to support you on that.

Regards

[gab-k]

Hey,
I was also about to answer to this discussion, because after taking another measurement today I also observed this behaviour. I'll post the screenshot in a second.

The 7 V overshoot certainly seems excessive and will probably destroy the hardware in the long term.

Thanks for making the effort of taking measurements and giving a detailed description @hebalazs @Space-Farmer

Edit:

[Space-Farmer]

Gude,

unfortunatly, the MCP1799 is not that available for a quick fix, what do you think about the following one?
TS78L03CX

This one has a higher quiecent current, but that should not matter that much in this application.
Did you already had the change to measure current consumption for the 3V3 Rail?

[gab-k]

Looks alright to me. Current consumption is around 30mA. Of course sourcing current from GPIO will add to the overall consumption.

[Space-Farmer]

Don't use the TS78L03CX footprint did not match :-(
I ordered some MCP1799 in Czech republic.
@gab-k if you need some parts, please write PN

[gab-k]

Oops, I must have missed that.

[Space-Farmer]

After making a lot of test with changed capacitance on input and output side, I come to the point that the huge overshoot is only related to the fast turn on edge of the voltage input. Which looks for me that LDO is not acc. to the datasheet to not call it bug.
Therfore I contacted Dongguan Pingjingsemi Technology Co., Ltd.
Who up to my surprise answered quickly.

For our PJ75AL33SA, there is a certain output spike issue, it can have an impact in certain applications. I'm not sure if sales told you before when choosing this one.
To solve the problem well, I recommend PJ75BL33SA as an alternative.

@gab-k : please remove that part from your schematic.
Alternative different footprint: TI TLV76033DBZR LCSC part no. C2683368
Alternative same footprint: HE2021A33HMR
CJ6386A33M (this one might have a soft-start function acc. to the datasheet figures)

[gab-k]

please remove that part from your schematic.

For now i just added a note linking to the issue i opened which references this discussion until i found a replacement that i find to be working.

Alternative different footprint: TI TLV76033DBZR LCSC part no. C2683368
Alternative same footprint: HE2021A33HMR
CJ6386A33M (this one might have a soft-start function acc. to the datasheet figures)

I don't want to change the footprint. CJ6386A33M looks promising. To be honest, a voltage regulator is actually such a standard component that I never expected that such problems could arise, which is why I never had the idea to measure it. I actually think that most voltage regulators would work fine (without overshoot).

As already indicated above, I have ordered several voltage regulators for evaluation and will then adjust the circuit diagram afterwards.

@Space-Farmer Unfortunately I can't send you a private message on github.

[gab-k]

I have changed the schematic, removing the previously used LDO, replacing it with an alternative part that should work better. Another alternative part can be found below the BOM in the wiki.