Level translation

[diggit]

I've seen several other probes with level shifters, and tracking T_VCC to get TRANS_VCC is not very common. It puts high requirements on regulators (very low drop) and probe itself.

Common approach, was to use low (quiescent) power level translators and power them directly from T_VCC. Such option is eg. AXP logic from NXP. 74AXP1T45 has quiescent current below 1uA. Dynamic power consumption would be covered by caps and one voltage regulator could be omitted (U14).

Is there some other reason for current design?

[korken89]

Hi, sorry for not coming to this. Could you expand on the issue, I don't see what you mean?

The reason for this is that we don't have any guarantee on the power delivery on T_VCC, and throwing in an extra LDO to make it a non-issue was a no-brainer to me. Debugging intermittent power issues on T_VCC sounds like a nightmare to me, hence the current design.

[diggit]

Even though, you are saving several uA being drained from T_VCC by supplying level translators separately, you are adding current drain by having extra voltage divider R14/R15, consumption from T_VCC is increased by 50uA. By having this "tracking" regulator for level translators and you are adding some delay between T_VCC and level translators using it. There are devices which dynamically change their VCC to conserve power. For comparison, J-link probes just feed T_VCC into level translators VCC. I never had issue there. J-link base consumes 30 uA from T_VCC when there is 3V3. btw Mouser tells NCP133BMXADJTCG is NRND.

I just don't see reason to add this extra complexity into circuit for no obvious gain.

[korken89]

Hi, thank for the comments.

Even though, you are saving several uA being drained from T_VCC by supplying level translators separately, you are adding current drain by having extra voltage divider R14/R15, consumption from T_VCC is increased by 50uA.

If someone really needs that we load T_VCC less it's fine to replace the voltage divider with larger value resistors, 1 Meg should do fine for example. However the leakage through the translators and target pull-up will be much larger than the contribution of the divider.

By having this "tracking" regulator for level translators and you are adding some delay between T_VCC and level translators using it. There are devices which dynamically change their VCC to conserve power.

Indeed there will be a delay, however it is quite small. About a millisecond if I remember correctly with the current setup. I don't see that this would cause issues, as when the target goes into a low power state the debug unit will be disabled. The important part then is that RESET continues to work, and it's an open-drain output which is independent to target voltage.

btw Mouser tells NCP133BMXADJTCG is NRND.

This part is no longer used in the design. Please have a look at the latest version for updated parts.

I just don't see reason to add this extra complexity into circuit for no obvious gain.

You can have a look at my previous reply for why and the gain it has. The other part is when targets don't have T_VCC connected, which is common for breakout boards - then you can still set the level manually.

I obviously see a gain, you don't - however you have not convinced me that there is an issue with the current design. If you want to see something changed I need clear pros-cons.

[diggit]

This part is no longer used in the design. Please have a look at the latest version for updated parts.

I just looked into schematic linked in readme in master branch.

I don't see that this would cause issues, as when the target goes into a low power state the debug unit will be disabled.

1. eg STM32 can be told to leave debug unit powered in deep sleep, so it does not apply universally
2. There are boards with always on LDO (eg 2V) and with DC/DC (eg. 3.3V), outputs connected together. DC/DC is enabled when there is needed more power for target (and other components.) Yeah, due to capacities on power rails, these changes won't be fast...

Also, is this tracking done as closed loop or open loop? Closed loop puts some requirements on regulator (stability), open loop requires extra calibration.

however you have not convinced me that there is an issue with the current design. If you want to see something changed I need clear pros-cons.

That is right attitude. Let me try a bit more.

My attitude: "When there is no gain from something, why have it there?"

I obviously see a gain, you don't.

You can have a look at my previous reply for why and the gain it has.

Previous reply

The reason for this is that we don't have any guarantee on the power delivery on T_VCC, and throwing in an extra LDO to make it a non-issue was a no-brainer to me. Debugging intermittent power issues on T_VCC sounds like a nightmare to me, hence the current design.

What could cause those "intermittent power issues on T_VCC"? Can you describe such situation? I am genuinely interested.

Maybe I am just missing something here or it just never occurred to me.

In the end, you have total control over this project and I am just some stranger on the internet. :slightly_smiling_face:

[korken89]

Hi, thanks for the comments!

I just looked into schematic linked in readme in master branch.

There is no schematic in the master branch anymore, you must have looked at an old version. The README now points to the GHA where schematics are generated. You would have to look at the latest commits' artifacts to get the schematic now.

There were some old PDF exports in the repo, I deleted them now.

Also, is this tracking done as closed loop or open loop? Closed loop puts some requirements on regulator (stability), open loop requires extra calibration.

It is open loop, but you only need to be accurate enough so the internal ESD diodes do not start conducting which generally means you need to be within +/- 0.5V. In my testing we are within 20 mV using the ideal formula so I see no need for calibration.

What could cause those "intermittent power issues on T_VCC"? Can you describe such situation? I am genuinely interested.

Absolutely as this has happened for me. Any oxidation on T_VCC's pad is generally enough to start having issues. It's fine until the translators switch at which point the T_VCC droops. And I do not want this to be an issue.

[diggit]

Any oxidation on T_VCC's pad is generally enough to start having issues. It's fine until the translators switch at which point the T_VCC droops. And I do not want this to be an issue.

I see. Higher resistance of T_VCC line is definitely possible and could cause issues, but that applies to all other signals too. I'd rather be notified in such case than have HW silently working around it, because if there is issue with T_VCC, other signals could have some issues too and there is no workaround for them...

My point is, this added complexity solves possible issue with only one "signal". So you have to keep care of your debug connections anyway.

---

Looking at regulators U13/U14, NCP133AMXADJTCG is used. I noticed that these regulators can handle only 3.6 V as max output. There are 5V capable targets, for example Nuvoton Cortex M0.

What about same regulator for all 3 power rails? It would reduce BOM.

Do sou want to discuss these in separate issue?

[korken89]

On the T_VCC issue vs other signal, this is handled by the JTAG/SWD communication and its checksum. So you'll get errors if the communication is shaky (CRC error). The only signal not having a backup was T_VCC to the translators.

On the 5V support, this is not an aim with this board - it's designed around 3.3V maximum. A different board could be made with "extended voltage range".

I checked trying to consolidate the BOM before, and it was not possible due to space. (EDIT: This is now done) Now it can probably be done, one will get a new resistor value to the BOM instead.

[diggit]

On the 5V support, this is not an aim with this board - it's designed around 3.3V maximum. A different board could be made with "extended voltage range".

It's a pity. The only necessary changes would be different regulators and dividers.

Anyway, this is probably resolved issue, closing.