We are trying to implement Challenge/Response Mechanism using Segger J-Link and VisualGDB on i.MX-RT1051
This mechanism is used to lock JTAG interface in manufacturing process to increase security of system. Authorized re-activation of JTAG interface possible in field-returned devices.
NXP recommends Lauterbach TRACE32 debug tool. Segger J-Link is not supported yet.
Mechanism is very simple, and described in 2.1.2 Debug flow when Secure JTAG mode is enabled (see application note above).
Our question: how we can implement such Challenge/Response Mechanism using VisualGDB?
This is normally something handled by the Segger GDB stub (VisualGDB launches it with the parameters you specify via settings and expects it to take care of the low-level JTAG interaction and provide high-level debugging information to gdb), so please check with Segger support if this is possible with their tools.
If not, you could try using OpenOCD instead. If secure JTAG is not supported by it yet, you could patch it (consider using our easy-to-build OpenOCD fork), wait for someone else to contribute the patch, or we could add it for you via our paid customization services.
You are right, it can be done using GDB stub. Thanks for good advice! Now we have another question.
Now we use JLinkScript file, and have two options:
– rename file to Default.JLinkScript and place it into j-link directory C:\Program Files (x86)\SEGGER\JLink_V632d
– in VisualGDB Project Properties –> Debug settings –> Advanced settings –> Command line –> add argument -jlinkscriptfile C:\test_script.JLinkScript
Both options are not suitable for us, because developers works not only with NXP RT1050 (so Default.JLinkScript shouldn’t be used for another MCUs), and absolute path to repository also different (we can’t specify relative path using -jlinkscript argument)
Our question: What is the right way to set JLinkScript file for only one project in the VisualStudio solution?
The options in the VisualGDB Project Properties (except the J-Link executable path that is shared) are actually defined per project/configuration pair, so it’s safe to use the second setting you mentioned.
Please try using the $(ProjectDir) variable to avoid hardcoding absolute paths.