By which indicator does SNVS detect JTAG activity

[ffm]

I'm trying to enable HAB on a IMXRT1062 MCU built into a custom board, which by design has the JTAG wires connected to a boot chip. This boot chip detects a virgin MCU via those JTAG wires and injects a default binary image. This boot chip can also be used upon request to non-securely updating the SW running on the MCU by injecting a secondary bootloader image into the MCU's RAM which then loads the application SW image by means of USB.

Meanwhile I built a secondary bootloader which is meant to persist in the first few sectors of the external flash so that JTAG access for the boot chip may be disabled in the IMXRT. I'm able to sign and successfully run the bootloader image on the MCU in open configuration, so there are no HAB events.

By setting the device to secure configuration I'm no longer able to start the image. I tried to reproduce the the steps on a MIMXRT1060-EVK on which the image is successfuly running also in secure configuration, but only if JTAG is not connected. As soon as a JTAG debugger is actively attached, the image doesn't start anymore and I was able to figure out the reason, which is most probalble a security violation reported by SNVS due to the attached JTAG debugger.

I built in a function into the bootloader image which dumps the SNVS registers and indeed when running on a fresh board with a MCU in open configuration it shows SNVS_HPSVSR.SV1 = 1. Unfortunately on the custom board I cannot disconnect the JTAG wires, so I tried to step-wise disable JTAG access by means of eFuses.

The first unexpected observation was, that after burning JTAG_SMODE to 0b01 (Secure Jtag) the boot chip was still able to access the MCU by means of JTAG access (still SNVS_HPSVSR.SV1 = 1). Same observation was made after burning JTAG_SMODE to 0b11 (No Debug). Finally after burning SJC_DISABLE to 1 the boot chip was no longer able to inject an image, but still SNVS_HPSVSR.SV1 is 1, which leads me to the question by which indicator the SNVS is detecting JTAG access.

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
SNVS_HPSVSR.SV1 is able to indicate the JTAG attached, however, it doesn't mean that the MCU is accessed by the JTAG tool actually.
In further, I'd like to suggest you go through the AN12419
Secure JTAG for i.MXRT10xx to learn how the Secure JTAG on the i.MX RT10xx MCU family can be used.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[ffm]

Ok, I found a resonable explanation, why with burnt JTAG_SMODE the boot chip was still able to access the IMXRT. AN12419, Chapter 2.3 mentions that KTE fuse also has to be burnt to have JTAG secure mode work. Referring tp figure 1 I misinterpreted the boolean equation explaining when the access to the CM7 DAP is disabled.

Anyway, what remains is the question why with JTAG access competely blocked (including boundary scan) the SNVS still complains about active JTAG (SV1).

[jeremyzhou]

Hi,

Thanks for your reply.
Yes, I think your latest explanation can explain the phenomenon that the boot chip is still able to access the MCU by means of JTAG access even after burning JTAG_SMODE to 0b01.
I'm a bit confused with the meaning of secure configuration and open configuration in your previous statement, whether you can clarify them.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[ffm]

Yes, by "open configuration" I mean eFuse SEC_CONFIG = 0 (not burnt) and "secure configuration" I mean eFuse SEC_CONFIG = 1 (burnt).

[jeremyzhou]

Hi,
Thanks for your reply.
In my opinion, SNVS_HPSVSR.SV1 is able to indicate the JTAG activity even the disable the JTAG via burning the eFuse.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[ffm]

Ok, but what kind of signal does it look for on which pins? I mean all those JTAG pins can be used as general purpose or peripheral IO pins. And if in this function some external signal is applied to them, may it be during power-up or later on SNVS should be very careful treating those signals as JTAG activity. SNVS seams to be very sensible regarding JTAG activity. So are there any signal patterns to be avoided at the JTAG pins in order not to trigger SV1?

Regards, Frank

[ffm]

Thank you for your response. According to the Security Reference Manusl for the i.MX RT1050 Processor, Rev. 1, 04/2018, Chapter 10.1 the security violation input 1 is linked to "JTAG active". In fact, it is not clear what this actually means. From my experiments with the MIMX1060-EVK I can say, that just hookng up the debugger to the 20-Pin debug connector on this board doesn't lead to SV1, but when I actively connect to the processor with the debugger application the SV1 gets set while the SSM transitions from "Trusted" to "Soft Fail".

I already read your mentioned document and it states, that after burning JTAG_SMODE to 0b01 (Secure JTAG) access to the CM7 DAP is no longer possible. Instead you have to connect to the SJC by Challenge-Response-Authentication. Obviously this was not the case as the boot chip on the custom board was still able to access the processor by means of JTAG and it doesn't use Challenge-Response-Authentication.

But this is actually not the point. The point is, that even on a IMXRT, which has JTAG access nearly completely blocked (the only remaining fuses are KTE and JTAG_HEO) and even the boot chip cannot access the IMXRT via JTAG, SNVS reports SV1 - "JTAG active".

So it seams SNVS is looking at some or all of the JTAG pins and does competely ignore that JTAG access is blocked. The problem is that I cannot prevent the boot chip from tryint to access the processor via JTAG, but due to the fact that JTAG access is blocked by the MCU i would expect that SNVS doesn't report SV1 anymore.

Unfortunately the mentioned document AN12419 doesn't give background information related to SNVS. Thus I try to understand what makes SNVS still report SV1 in order to get an idea what might be necessary externally on the JTAG wires to satisfy SNVS.

Regards, Frank