How to debug netX 90 application side with J-Link debug probe from SEGGER?
How to debug netX 90 application side with J-Link debug probe from SEGGER?
Hilscher provides netX Studio CDT IDE (Integrated Development Environment) for customers for developing application software for the netX 90 SoC. The main goal is to provide an out-of-the-box working solution for building and debugging applications for the netX SoC. netX Studio CDT is provided to customers free of charge and aims to make it easy for them to evaluate netX as a platform for their custom designs. The software (https://hilscher.atlassian.net/wiki/display/NDT/) and Documentation are available on Hilscher Knowledgebase(https://hilscher.atlassian.net/wiki).
SEGGER's J-Link supports a wide range of CPUs and is very popular with some netX customers. Since SEGGER added support for netX 90, which allows customers to use the tools from the J-Link Software and Documentation Pack and the Ozone J-Link Debugger, we provide here a step-by-step guide for debugging the netX 90 application side with J-Link.
1. Prerequisites
Please use J-Link Software and Documentation Pack v7.60 or later.
The v7.60 release includes the following fixes for netX 90:
Hilscher NetX90 Com Core RAM base address for RAMCode was wrong. Fixed.
Hilscher NetX90 Com core reset and halt after bootloader handling, fixed.
Hilscher NetX90 Com core used software reset instead of reset pin toggling within reset routine. Fixed.
For use case B and use case C with an external SQI flash, please use J-Link Software and Documentation Pack v7.86c or later.
The v7.86c release includes the following new feature for netX 90:
Hilscher NetX90: Added SQI(QSPI) flash programming support.
2. J-Link support in netX Studio CDT
Currently, netX Studio CDT supports debugging with J-Link in one of the following two ways:
J-Link with OpenOCD (not recommended)
J-Link with GDB Server (not recommended)
2.1. Using J-Link with OpenOCD
In general, it is possible to use J-Link with OpenOCD, but it's not recommended due to the following main reason:
To use the J-Link debug probe with OpenOCD, you have to replace the original J-Link USB driver with WinUSB using a tool like Zadig.
It does not make use of any high-level logic etc. and therefore is much slower than the proprietary SEGGER J-Link DLL / GDBServer / ... implementation.
Once the J-Link USB driver has been replaced, no SEGGER software from the J-Link software package will be able to communicate with J-Link anymore. To use SEGGER J-Link software again, the USB driver needs to be switched back to its default.
Please see further limitations and support from SEGGER: https://wiki.segger.com/OpenOCD
2.2. Using J-Link with GDB Server
netX Studio CDT supports debugging with a different GDB server backend than OpenOCD, e.g. SEGGER J-Link GDB Server. (Please refer to the attached example project, which has ready-to-use batch scripts for programming the flash and starting the gdb server etc. by calling the batch file in the Terminal of netX Studio CDT.)
It's not recommended as well, since to use the full feature of J-Link Debugger, Ozone is supposed to be used. If you still want to use netX Studio CDT as a frontend, please note the following:
Start J-Link GDB Server (Run jlinkgdbserver_run.bat) before starting debugging in netX Studio CDT
Disable "Start OpenOCD automatically" in Debug Settings →Target Settings
Don't choose "Load image (gdb load)" if the application is running directly in internal flash (The NAI firmware must be flashed manually before debugging.)
Remote Target's "Host name or IP address" should be localhost and the Port number should be 3333.
To debug applications on SDRAM, the SDRAM must be available and configured correctly. (NXHX-SDRSPM extension board must be connected if NXHX 90-JTAG board is in use.)
Remote target port
By default J-Link GDB Server starts at port 2331. In the example scripts, the port is set to 3333, the default port for OpenOCD. The “Remote Target” settings were introduced in netX Studio CDT V1.1000 where you can configure the port and set it to 2331. For older netX Studio versions, the remote target port is hard-coded to 3333 so JLinkGDBServer.exe has to be started with the option “-port 3333”.
Hardware reset
By default J-Link performs a reset via the SYSRESETREQ of the Cortex-M CPU. The setup_target.jlinkscript included with the example configures J-Link to use a hardware reset via the RST_IN_N pin. See https://wiki.segger.com/J-Link_Reset_Strategies for more info.
3. Using J-Link with J-Link Debugger — Ozone
Ozone is tightly coupled with SEGGER's set of J-Link debug probes to ensure optimal performance and use experience.
The Ozone_example has ready-to-use *.jdebug project files for Ozone:
pns_simpleconfig_sdram.jdebug – fordebugging the application from SDRAMpns_simpleconfig_iflash.jdebug – fordebugging the application from the internal flash
The two Ozone project files in the example have different predefined functions on specific events: on loading the project, before and after target download/reset etc.
3.1. Debugging project: pns_simpleconfig_sdram.jdebug
To debug the ELF file “pns_simple_nx90_app_usecase_a_sdram.elf” generated by netX Studio CDT, SDRAM must be configured in the HWC file correctly, and the application CPU must be enabled.
Note: If the NXHX 90-JTAG board is used as the hardware to debug the netX90 application, as SDRAM is not available on board, the extension board NXHX-SDRSPM (AN: 7703.080) must be connected!
To debug the netX 90 application from the external SDRAM, the netX90 is working as a stand-alone chip, a valid loadable firmware must run normally on the communication side. To achieve that, the netX90 device has to be flashed properly with a set of binary images that match together. Usually, the device has to have the following images flashed: HWC, FDL, NXI, and NAI. Hilscher flasher tool, as well as J-Flash, can be used for that.
Please refer to the “Boot process” of the netX 90 Production guide manual for further information.
If all the images are properly flashed, open the pns_simpleconfig_sdram.jdebug project, and you can debug it with Ozone directly. The source codes as well as the original netX Studio CDT project are also included in the Ozone_example.
3.2. Debugging project pns_simpleconfig_iflash.jdebug
For the project pns_simpleconfig_iflash.jdebug, the application internal flash is used instead of external SDRAM, so SDRAM is not necessary for this case. However, the following restrictions must be observed!
In this case, the netX90 device must be properly flashed with a set of matching binary images as well.
Since the ELF file “pns_simple_nx90_app_usecase_a_iflash.elf”, which is generated by netX Studio CDT, does not contain hboot information. If a target download is made, it would overwrite the NAI file without the correct hboot information in the application internal flash, then the communication firmware could not start the application CPU as expected due to validation failure.
So in this case, the target download is specifically deactivated!
By starting a debug session with pns_simpleconfig_iflash.jdebug, “Attach to Running Program” or “attach & Halt Program” can be used.
If "Download & Reset Program" is chosen to start debug session, the following Error dialog will pop up, you can choose "No" to continue the debug session, if *.NAI file is already flashed manually.
You can also open the interested source codes in the example manually, and set breakpoints. By calling "Reset & Run", you can restart the program and debug it normally. The only limitation is you should not download the ELF file to the internal flash!
Hilscher can only provide the workaround solution now, but an ELF update tool is in planning and a normal debug from internal flash will be supported in the future.
4. References