POR_B and JTAG_TRST_B / JLINK debug

[demoniacmilk]

Hello community,

I am wondering about the POR_B and JTAG_TRST_B signals.

On the SABRE board the POR_B signal is connected to anything related to reseting the system (PMIC, MX7, IO extender, watch dog, JTAG connector). But there are pretty much two exceptions:

1. the JTAG_RST signal on the JTAG header is connected to POR_B using a shottky diode 
2. JTAG_TRST_B on the SoC is not connected at all because of a non populated resistor

On my custom Hardware I used a shottky diode between the JTAG connector and POR_B as well but the SOC and JTAG connector have the signal JTAG_TRST_B connected on the PCB.

What are the effects of this connection?

I can see the two boards behave slightly different when attached to a segger jlink.
Custom Hardware:

Feature(s): GDB
Checking target voltage...
Target voltage: 1.81 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x5BA00477 (Cortex-M4)
WARNING: CPU could not be halted
Halting target device failed. Trying again with reset
WARNING: CPU could not be halted
Failed to halt target device on connect
ERROR: Could not connect to target.

SABRE board:

Feature(s): GDB
Checking target voltage...
Target voltage: 3.32 V
Listening on TCP/IP port 2331
Connecting to target...ERROR: Bad JTAG communication: Write to IR: Expected 0x1, got 0xF (TAP Command : 10) @ Off 0x5.
Could not find core in Coresight setup
ERROR: Could not connect to target.

May this be related to the difference in the reset signal?
What else may cause this behaviour?

[sinanakman]

Hi Lars

I don't have answer to all your questions but wanted to let you know that

I had tried imx7D sabre board with another debugger (BDI3000) sometimes

ago and I was able to connect successfully.

Few things might be of help to note :

- On the sabre board TRST is not connected as you noticed and your

debugger needs to be instructed to leave it opendrain and use instead

a different sequence to reset the tap (e.g. tck/tms high)

- Debug communication is not possible while RESET is asserted so you might

have to instruct your debugger  to communicate only after the reset is completed

- M4 is on another AP so it is possible that after your debugger connects to

the target (perhaps successfully) it changes the AP number. While you are on

that AP it won't be able to access the debug registers to halt the A7 core.

If your debugger comes with config scripts for the board you are trying to debug

check to see what it is doing for setting the AP.

Hope this gives some pointers.

Regards

Sinan Akman

[igorpadykov]

Hi Lars

please look at Figure 4-36. SJC Reset Logic i.MX7D Reference Manual

http://cache.nxp.com/files/32bit/doc/ref_manual/IMX7DRM.pdf

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[demoniacmilk]

From the figure it seems like it really doesn't matter what reset is pulled down, as DAP and TAP are reset anyways. On the the SABRE only POR will be pulled down, but because TRST && POR its the same result as pulling both POR and TRST.

Any idea/thought on the JLINK console outputs?

"bad jtag communication" does not sound like a proper result for a demo board, but I am not sure what might be going wrong. Especially as the core schematic on the custom hardware is somewhat similar to the sabre.

[igorpadykov]

one can check JTAG_MOD state on both boards and

try with other debugger.

Best regards
igor

[demoniacmilk]

JTAG_MOD is low on both boards.
I do not have another debugger.

I checked the POR_B and TRST pins with a scope and on the custom hardware they seem to remain high all the time, while on the sabre I can see the signal being pulled low several times.

edit: on the custom hardware JTAG_RST (through a Shottky diode), POR_B on the SoC and RESETBMCU on the PF3000 are connected. No external pullups/downs.

[demoniacmilk]

Hmm ... the JTAG interface is running on 1V8.

I measured voltages for  TRST and POR. TRST was at 1V8 , TRST at 2V2.

After removal of a the diode between the two signals POR is actually 3V3.

there was probably a current flow from POR to the TRST pin. May this damage the device?

This also means i cannot keep the two reset signals connected, as POR will be a bit low for a 3V3 signal.
Just triggering TRST with the emular should be enough? or does POR need to be triggered as well?

The figure you mentioned in the reference manual shows an AND connection between POR and TRST. What happens if these signals are on different voltage levels? I assume both have to be high for the system to NOT reset, correct?

I can measure TRST activity (20 ms pull to low) from the emulator with the diode removed.

[demoniacmilk]

I added FETs to have both reset signals on their respective voltage and be pulled down together whenever TRST is pulled down.
I still cannot connect using the JLINK debugger. It does find the M4 and reads the JTAG ID, but it says "CPU could not be halted". What might be the reason for this?