STM32H747(XI) JTAG Sensing

[Discoinferno]

We have a new board that uses the STM32H747 MCU and is based on an existing, proven design.

Despite being schematically identical, the MCU on the new board cannot be detected by the STLINK-V3SET programmer and STM32Cube software. For whatever reason, when connected it delivers 5V to the TVAPP pin and says "cannot find target MCU".

• The voltages, connections and passives are identical between the working reference design and our new design.
• The programmer works on the reference board before and after trying our new board.
• The programmer works on the reference board even with the TVAPP wire cut. (The MCU is powered by 3.1V supply and the TVAPP is connected to another part of the PMIC that delivers 3.3V to other peripherals.) Again, this works perfectly on the reference design board.
• With or without the TVAPP pin connected to the reference board, the programmer never delivers any voltage to the TVAPP pin on the reference board.
• We have checked all of the connections and voltage and aside from a little different PCB layout, our PCB and schematic is identical to a reference design that works perfectly with the same programmer hardware and software.

Can someone please help ASAP to explain how the voltage and MCU sensing/detection works so that we can do some debugging? It is not over the TVAPP pin as mentioned in the user manual, because it works on our reference design whether it is connected or not.

I would like to know what the programmer is seeing or measuring that is different so that we can troubleshoot and find a solution.

I have checked the voltages and resistances to ground and they are identical.

We do have a small mezzanine connector and adaptor board for the JTAG, perhaps the JTAG is extremely sensitive...?

Can someone please let me know how the programmer detects the MCU and decides when and what voltage to deliver?

Also any tips on how to trouble-shoot further would be extremely appreciated.

Thanks!

[TDK]

What is the TVAPP app pin? This doesn't appear in the V3SET user manual. Did you mean T_VCC? Assuming so:

If it's delivering 5V to the programmer, you have a hardware problem. That pin should be tied to VCC you're using on the MCU. If it's 5V, that explains why the chip isn't responding as voltage should be under 3.6V.

As for how to debug, bunch of ways, here is one:

• Unsolder the STM32 chip. Check VCC. Is it still 5V? Problem lies elsewhere. (if not, then check that the STM32 is correctly oriented with no solder bridges).
• Trace upstream of VCC and find out where/why the voltage goes from correct to incorrect. Verify the chip responsible is doing its job. Presumably there's an LDO taking 5V and outputting VCC, or something similar.

[Discoinferno]

HiTDK thanks for the reply.

The 5V is coming from the programmer, not the board. Even when i cut the programmer wire pin 1 of the ribbon cable, before connecting it to the board, the programmer has 5v on that pin/wire. It also only shows up when the programmer is connected then the board is powered up.

Somehow the programmer is detecting something and deciding that instead of not providing power at all (like it does on the reference board), it needs to provide 5v but also not see the mcu.

[TDK]

Pin 1 of what connector?

Again, "TVAPP" doesn't appear in the user manual or the pinout. Did you mean T_VCC? Or where did you find the pin name TVAPP?

[tjaekel]

Are you referencing the SWD connector or an ARM JTAG connector (20pin)?

What is pin 1?
On STM SWD debug connector it is not connected. On an ARM 20pin JTAG adapter it is VDD.

Actually, the debugger ST-LINK (and even for 20pin ARM JTAG connector) does not provide the power for the board. Instead, these VDD pins are used to sense the power on the board. A debugger will not power the board, it wants to see the VDD power at the board via an input pin on debugger.

It sounds to me as well: you provide MCU VDD (and on board) as 5V (not 3.3V).

What is your schematics, pinout for the debugger connection?

Here my SWD connector for an ST-LINK debugger.
The VDD is not provided by ST-LINK: it is a sense signal ("what is target VDD?") as well as the 100R to GND: "is there a connection?".

Bear in mind, that some SWD connectors on other boards (e.g. Portenta H7) can be a bit larger, for instances see here:

https://electronics.stackexchange.com/questions/595103/stdc14-connector-pinout-for-st-link-v3-for-swd-debugging

Find really the important signals, e.g. SWDIO and the VDD (3.3V) opposite to it. Do not rely on "pin 1", esp. if your connector is a bit larger as "usual", e.g. on Portenta H7:

[Discoinferno]

Thanks for the reply, much appreciated.

Just to clarify, indeed it is the VDD pin. On the portenta H7 it would be the 3V3 line, pin #1 of the JTAG header. I hope that clears it up for everyone but can see that everyone already knows what I mean. See below image of the H7 JTAG pinning.

 

The MCU, PMIC and JTAG on my board are wired exactly the same as in the H7 and ethernet shield and so would hope and expect the same functionality and result. The VDD pin on the H7 ("+3V3" line) remains at 0.0V until the MCU is programmed and code uploaded to turn on the PMIC regulator that supplies this line. So any sensing by the programmer of VDD pin #1 of the JTAG connector will only turn up 0.0V from start to finish.

I don't supply 5V to anything except the input of the PMIC. I have even checked all the IO and JTAG pins as well as the power input lines and all decoupling capacitors to the MCU. There is nothing more than 3V1 anywhere.

However, when I connect the programmer to my board, the VDD line from the programmer goes to 5V and the STM32Cube software cannot find the MCU. I confirmed this by cutting the wire to pin #1 and testing it while trying to connect and program on both boards. (H7 programmed and worked fine with this wire cut and was only at 0.0V the whole time. With my board, it goes directly to 5V on the programmer side).

I can assure you that indeed the STLINK-V3SET does indeed supply voltage. I do not know what signals it is receiving or how it is interpreting what it sees it to trigger performing that action, but it is supplying 5V towards the VDD pin #1 on my board with reference to the programmer ground pins.

I've checked the levels of each of the pins with the programmer disconnected and power to the board and they are the same as the H7. Thats why I am very curious to know which conditions trigger the programmer to deliver voltage and what criteria is uses to send 5V instead of for example 3.3V.

Just to reiterate; after connecting to my board and the programmer trying to inject 5V on VDD, I connect it again to a portenta and it works perfectly normally and is able to connect, erase and program the H7. VDD remains at 0v the whole time. So there seems nothing wrong with the programmer and in fact I already bought a second programmer in case the first was faulty.

Does anyone know what exactly the programmer does to decide if and when to supply 5V to VDD?

With the H7, the 14-to-20 pin ribbon cable from the STLINK-V3SET connects directly to the ethernet shield (per the diagram above). On my board I use a small adaptor PCB to go between the same 20-pin connector on the ribbon cable to a small mezzanine connector on my PCB (To save space on the PCB).

Could it be that the programmer is soooo sensitive that the additional PCB track lengths (max 20mm extra) are causing it some kind of interference and confusion? (I don't see noise or anything like that whatsoever on the oscilloscope when I sniff it out).

[Discoinferno]

Does anyone have access to information about how and when the programmer delivers +5V?

We have boards sitting idle and customers waiting while we try to debug. We are at a dead end, any insight from ST would go a long way to enabling this product launch and become a success.

[TDK]

> Does anyone have access to information about how and when the programmer delivers +5V?

You're ignoring what we're telling you: the programmer never delivers +5 V under normal operating conditions. It's an input pin on the programmer. Perhaps it was damaged. Also possible is you are mistaken about what is happening, or not presenting the full story here.

[Discoinferno]

You’re ignoring what I’m telling you; I have 2 and they most certainly do.

They both also function as expected correctly when connected to the H7.

If the VDD wire is cut and only connected to the programmer, where else can the 5V come from that appears on the VDD wire?

And why does it decide that when connected to the H7 that 5V is unnecessary?

If it was behaving as expected, I wouldn’t be here asking silly questions and being mocked and told that what I see is some kind of fantasy.

I am here looking for help debugging something that is not in the user manual and seems out of the ordinary.

[tjaekel]

I think, a debugger never provides VDD (to power the target board) on the JTAG header.
The debugger does not know how much power (current) has to be provided. And why 5V? Most targets run at 3V3.

The debugger has just a sense pin (to "read" the target VDD), in order to know how to setup JTAG pull-ups (and if the target is powered!).

If pin 1 goes to 5V when programmer is connected - I can only imagine: there is a weak pull-up to 5V.
I am pretty sure, you cannot draw any current on programmer VDD sense pin 1!
Or: more likely: there is an ESD protection diode involved, providing this 5V, to make sure the input signal on pin 1 (and it is for sure an input/sense on programmer) never exceeds 5V.

That pin 1 is 0V until MCU has programmed the PMIC - obvious: it depends on the schematics: if VDD for all other external components is just provided after MCU (getting boot power a bit differently) has configured the PMIC, then VDD has now 3V3 afterwards, otherwise "floating".

I can confirm this a bit this way: if your MCU FW is wrong and it would not configure the PMIC - the programmer cannot see anymore the target (the sense for VDD on target does not have power). So, the VDD populated on pin 1 is only there if the MCU has done something reasonable with the PMIC: if bootloader is not there and not done, if your MCU FW code crashes before PMIC config - the debugger cannot connect anymore (you need the procedure to recover from a "bricked" MCU board).

All voltage rails just 3V1: yes, this is correct: the default PMIC config is set to do this (3V1, not 3V3, on Portenta H7).

Measuring a voltage on a pin does not mean it is a power output pin!
(you need the schematics of the board in order to see if it could do so, but on a JTAG VDD Sense pin it is an output from board to the programmer).
Put a resistor on programmer pin 1 and see what happens: does the voltage drops (or it is even 0 now)? Measure the current through this resistor: do you think it will provide power? (for instance: programmer not connected and measure the short current, tie pin 1 on programmer to GND on other programmer pin: how much current do you see? Do you still think it is a power providing pin? - I do not think so.)

So, check your schematics:
the debugger/programmer needs at least two "sense" signals:

• pin 1: it is sense input for programmer to measure target voltage
• pin 9: goes usually via 100R to GND: it is sense for "connection done" (not a signal GND!)

Does your board provide the VDD (on board) at this pin 1?
Or do you expect pin 1 is a power input from programmer? (which is not!)

If you do not put the VDD on board to pin 1 - the programmer will never see your board.

Do you have schematics of your board? (at least to see how board VDD goes to pin 1)

Try this:

1. do NOT expect pin 1 on JTAG header is a power input (have a power input somewhere else, e.g. via your
   5V to PMIC and 3V1 out from PMIC)
2. wire (a small patch wire) from 3V1 out of PMIC, e.g. somewhere from another chip on board) to pin 1:
   populate board VDD on pin 1 for the programmer
3. Make sure the "GND sense" pin 9 is also there (besides the signal GND pins) 
4. Make sure, the bootloader is still in FLASH memory, it will still be executed, or your FW booting will configure PMIC.
5. Measure, if you see (without programmer connected) the 3V1 on pin 1. It must be there.

My guess: you (your board) do not provide VDD (3V1) on pin 1: instead, you expect to get power there (which is wrong).