Hello!
As we already discussed in this topic, OpenOCD and VSCode are apparently not a viable solution for Verdin right now. I finally got my hands on a Segger J-Link but I’m still having problems to connect with my board.
I want to use IAR IDE with it, following the “Getting Started with MCUXpresso SDK for EVK-MIMX8MM” pdf, chapter 4 “Run a demo application using IAR”. This should be a straight forward thing. But I have seen in many forum posts (e.g. here) that a certian patch is needed for the IAR to support the arm debugging and another patch for the segger as well. I tried with the SDK_2.3_MX8MQ_Beta_Patch (if I remember correctly).
When I try to flash the code from the IAR I get an error message "missing or malformed flash loader specification file " and when I try to connect directly through the JLink Commander I’m getting an error message “Error:Target voltage too low”
I think I’m probably messing up multiple things in this process so if someone managed to use this toolchain successfully on the Verdin Mini could give a short explanation, that would be lovely!
P.s. I would also rather do it with VSCode than IAR, but as discussed in the first topic linked above, VSCode has trouble finding the right executable. In this topic they seem to have solved this problem internaly through an email exchange. Maybe this secret solution will come to light too
I’m sorry for the long delay. After seeing your question, I tried here and I could use the JLink with the VSCode to debug the Cortex-M4. So I decided to write a developer page about it, so others can check it as well.
Unfortunately, I couldn’t test it on a Windows Host machine yet. Could you please try it and see if it works for you? This guide uses the Cortex Debug extension from VSCode which is also available for Windows, so it shouldn’t be a problem. My host machine where I tested it is installed with Linux Ubuntu 22.04.
I still need to check the IAR that you mentioned. I will get back when I have more updates on the IAR software. For now, let me know if VSCode is enough for you.
Please, also feel free to ask any questions related to this guide that you might have.
(@AhmedMobarez I’m tagging you here as well since I think it is a good topic for you too).
Thank you for the developer pages. It finally works with Segger and VSCode!
Just a few notes to the content itself:
-MCUXpresso SDK and Toolchain for Cortex-M development" in the prerequisities is not working for me.
-Links inside warning bubbles concerning external and on-board jtag are not working.
When it comes to testing the JTAG itself, I needed to add
Thank you for the input! I updated them, it should be online by the end of the day.
I’ve added the serverpath suggestion to the article. I should also be online by the end of the day. The device and armToolchainPath are in the article, I’ll make sure it is clearer.
Thank you! Good to know it’s working on Windows as well.
Feel free to ask any further questions you might have.
Hi @hfranco.tx ,
I have one additional question:
How can I make the M4 autoboot with the .elf file that I debug and deploy through Segger? We already discussed here how to autoboot a binary file and that’s the technique I’m still using. But when I deploy the .elf file over Segger and restart the Verdin, the old binary file from the /var folder (of course) boots back again.
It that even an option or is J-Link debugger only to be used during debug phase?
Thanks
I don’t think it’s possible to do that. JLink copies the .elf file to the right memory address and when you reboot the module, this memory address is cleaned and used by uBoot/Linux Kernel.
Despite of that, I’ll try to research something that could do this reboot and still be in debug mode, I don’t have anything that I can think of right now.
beside the patch I downloaded in the beginning to build the project, I didn’t do anything else for the debugger to work.
Also here is my debugger settings:
anytime, I forgot to mention I am using an Apalis Evaluation board with Apalis IMX8, hopefully that doesn’t affect you.
also, what I found to be working well for me is the Ozone debugger from segger, so even if you have issue with IAR you can just build and load the .out file into ozone and you would have a very good debugger
sorry for going back to this old thread, let me know if I should post a new question, I just wanted to know how and if the debugging worked with VScode on windows, I am not sure what changes are needed to the task.json and launc.json required to make it work with windows
Hi @AhmedMobarez ,
I am able to run the Segger J-Link together with VSCode is that’s what you mean.
I probably changed my .json files many times, not sure which settings are important for you but I’ll just copy them here for you.
Here is mine launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "cortex-debug",
"request": "attach",
"name": "Debug J-Link",
"cwd": "${workspaceRoot}/armgcc", // Put here the path for your armgcc folder
"executable": "debug/main.elf", // Select the path for your .elf executable
"serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe",
"servertype": "jlink",
"device": "MIMX8MM6_M4", //Select Your Device here
"interface": "jtag",
"postAttachCommands": [
"monitor reset",
"monitor halt",
"load"
],
"armToolchainPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin", // Select here the path for your toolchain
"showDevDebugOutput": "raw",
}
]
}
And my tasks.json :
{
"version": "2.0.0",
"options":
{
"env":
{
"ARMGCC_DIR": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin" //Put here the path to your toolchain
}
},
"tasks":
[
{
"label": "Build hello_world debug",
"type": "shell",
"options":
{
"cwd": "${workspaceRoot}/armgcc" // Put here the path for your build_debug.sh script
},
"command":
[
"./build_debug.bat"
],
"problemMatcher":
[
"$gcc"
]
},
{
"label": "Build hello_world release",
"type": "shell",
"options":
{
"cwd": "${workspaceRoot}/armgcc" // Put here the path for your build_release.sh script
},
"command":
[
"./build_release.bat"
],
"problemMatcher":
[
"$gcc"
]
}
]
}
Hi,
Never had that problem, but I can tell that that output looks much different for me.
No idea where this comes from. I tried using openOCD at one point so I installed many many different debuggers, only thing I know is that it’s working now
Try connecting using C:\Program Files\SEGGER\JLink\JLink.exe frist, maybe that cuts out some of the variables from your problem so you can pinpoint where the actual issue is.
So I am leaving this here in case someone faces the same issue, the problem was that python 2.7 was not installed but instead python 3.xx , gdb requires python 2.7 to work properly.
