How to configure Debug of K64F Zephyr/project in Eclipse?

[rjm]

According to NXP's Build Your First Zephyr Application on i.MX RT, it is well possible to debug an application that is built using west build. However, this document supposes the usage of Segger J-Link.

I don't succeed in configuring this via the LinkServer Debugger (the K64F built-in debugger interface). When I compare with a native MCUXpresso example (here: frdmk64f_dac_adc_peripheral), under the "Main" tab, the binary is specified as an .axf file. While the Zephyr Emalator Target says: zephyr/zephyr.elf.

My approach was to duplicate the Debug configuration for the native project and than alter entries in order to get it right for the Zephyr built application.

Hints are highly appreciated...

[rjm · Accepted solution]

Finally, I got it working. I took care about the gdb server. A JLinkGDBServerCLExe existed from an installed STM32 IceCube (experimented two days ago), but that seemed not to work (I don't remember what was wrong). Today I installed Segger's JLink_Linux .deb-package and I reprogrammed DAPLink with the Segger firmware. Install of the .deb-package initially resulted in an error: the installer failed to overwrite a /etc/udev/99-jlink.rules (quite sure from former IceCube install). Even renaming did not work. Only after executing sudo dpkg --remove segger-jlink-udev-rules, install of segger .deb-package succeeded.

Testing with the NXP MCUXpresso example dad_adc now did it! Automatically configured via GDB SEGGER Interface Debugging. Then I tried the Zephyr application. Duplicating the configuration for the former project did not work (I spend some words towards the end of this posting). So I went to follow the instructions of the (already) mentioned pdf "Build Your First Zephyr Application on i.MX RT".

Finally, it works using the GDB SEGGER J-Link Debugging scheme. In contrast to there, I had to fill in another device name (MK64FN1M0xxx12) and also put an absolute executable path (/usr/bin/JLinkGDBServerCLExe). The same applies to the GDB client setup (here: /usr/local/mcuxpressoide-11.5.1_7266/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.5.1.202201181444/tools/bin/arm-none-eabi-gdb). I had to set the usual macro variables for Zephyr project import by hand in order to be able to fill in a plain arm-none-eabi-gdb instead of the full path.

[rjm]

The only remaing problem yet: which file path to fill in the SVD path tab of the Debug Configuration. There is no such thing as a zephyr/ext/hal/nxp... path.

[ErichStyger]

SVD files are description files for the registers/etc (optional, anway).

They are usually part of the SDK, see 'SVD' in https://mcuoneclipse.com/2021/05/09/visual-studio-code-for-c-c-with-arm-cortex-m-part-4/

Not sure where they are in the Zephyr package/SDK, but you certainly can use the one from the MCUXpresso SDK (see above link).

I hope this helps,

Erich

[rjm]

Could you attach a sample xml file in a reply? Then I can identify which one is the correct one. Indeed a zip file exists in a MCUXpresso folder (/usr/local/mcuxpressoide-11.5.1_7266/ide/plugins/com.nxp.mcuxpresso.sdk.sdk_2.x_frdm-k64f_2.11.0.201911251446/sdks/), but a lot of xml files are inside. However, there is one file that exceeds by far the size of others (MK64F12.xml). Top part of content:

<?xml version="1.0" encoding="UTF-8"?>
<device schemaVersion="1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_1.xsd">
  <vendor>NXP Semiconductors</vendor>
  <vendorID>NXP</vendorID>
  <name>MK64F12</name>
  <series>Kinetis_K</series>
  <version>1.6</version>
  <description>MK64F12 NXP Microcontroller</description>
  <licenseText>Copyright 2016-2018 NXP
 SPDX-License-Identifier: BSD-3-Clause</licenseText>
  <cpu>
    <name>CM4</name>
    <revision>r0p1</revision>
    <endian>little</endian>
    <mpuPresent>false</mpuPresent>
    <fpuPresent>true</fpuPresent>
    <vtorPresent>true</vtorPresent>
    <nvicPrioBits>4</nvicPrioBits>
    <vendorSystickConfig>false</vendorSystickConfig>
  </cpu>
  <addressUnitBits>8</addressUnitBits>
  <width>32</width>
  <peripherals>
    <peripheral>
      <name>FTFE_FlashConfig</name>
      <description>Flash configuration field</description>
      <prependToName>NV_</prependToName>
      <baseAddress>0x400</baseAddress>
      <addressBlock>
        <offset>0</offset>
        <size>0x10</size>
        <usage>registers</usage>
      </addressBlock>
      <registers>

When getting it operating will still fail, I'll start a new thread for this.

[ErichStyger]

The MK64F12.xml is the correct one.

[rjm]

Many thanks. It does not work - I'll start a separate thread.

[ErichStyger]

can you add a link to that thread?

Keep in mind that for viewing SVD files you need a viewer, for example the EmbSysReg one:

https://mcuoneclipse.com/2014/09/27/updated-eclipse-embsysreg-viewer-with-extra-freescale-svd-files/

[rjm]

Link to "that thread": https://community.nxp.com/t5/MCUXpresso-IDE/Getting-an-imported-Zephyr-project-debugged-using-JLink/...

Just an hour ago, the peripherals view problem was resolved. It points out that the perspective in the imported Zephyr project case is automatically changed from develop into debug. I noticed that in the top right window (attached screenshot) several tabs existed where the space for the title was too limited to read. After expanding the width of the right window, I saw "peripherals". It was populated! In contrast to "peripherals+", which you see on the left side.

It was even populated with the tick boxes to select for the detail view - as I also saw in the i.MX RT pdf. The perspective+ operates via unfolding/folding peripheral entries.

[ErichStyger]

The LinkServer connection relies on the information in the SDK (device information).

So what worked for me is using the GNU MCU Eclipse extension (as in the slides, note that they are now part of Eclipse CDT) and point to the .elf file (just in case: .elf is just another extension for the .axf, it is the same file format).

I hope this helps,

Erich

[rjm]

Many thanks for the quick reply, Erich. Especially regarding .elf and .axf.
So it should work...
Regarding SDK: this means the information in - for example - an imported SDK example (dac_adc). So the approach of duplicating debugger config should work, or im I missing something?

Rob

[ErichStyger]

No, an 'imported' debug configuration won't work as far as I can tell.

But can reprogram the FRDM-K64F with a J-Link debug firmware, I hope you know this?

https://mcuoneclipse.com/2014/04/27/segger-j-link-firmware-for-opensdav2/

https://mcuoneclipse.com/2014/11/10/recovering-the-frdm-k64f-bootloader-or-cloning-the-program-of-a-...

Erich

[rjm]

Regarding DAP-Link firmware update, I already am a bit used to it. Just two days ago... (see my contribution here: https://community.nxp.com/t5/MCUXpresso-IDE/Debug-won-t-restart/m-p/1518620#M8372).

And today I also had the idea to try the Segger 2.0 firmware. However, It seemed to fail resources - at least a Segger GDB-Server, which must be specified in the path. Then I restored the original firmware. But At any case I'll try again when I see the prospect of getting it done. In a table on your website I notified the considerable speed differences. That makes that Segger is worth the money if I have to buy it for functioning beyond an eval kit. I already had the impression that the standard open source firmware is not fast. From my own experience on ARM/Cortex platforms I can only compare with plain old Code Red emulators, which were fairly good.