Date   

[Networking][socket] When is network is ready to accept a socket connection

Prabhu Vinod, Karthik
 

Hi,

 

I wanted to know if there are network events which I can subscribe, to know when the network init is complete. If there is one, I want to wait and use the callback to notify my app that then It can perform socket_connection. Because a socket connection on a non-ready network is blocking call.

 

I looked through include/net/net_event.h and found that there is NET_EVENT_IPV4_ADDR_ADD which comes closest to our use case since assigning IPv4 address to an network interface should be last thing to perform in a network_boot sequence. Is there something else that I could do?

 

Many Regards,

Karthik Prabhu Vinod

 

Help save the planet by choosing not to use single use plastics. Pick paper, bamboo or metal cutlery and carry your own bag to the grocery store. Every little thing you do makes an impact.


Re: [EXT] RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

Lawrence King
 

Hi Maureen:

 

The J-Link firmware for the LPC4332 on the RT1064has 2 issues, the first was rather easy to work around.

 

  1. The firmware doesn’t enable the “POWER_EN” signal (pin P3_1), hence the i.MXRT1064 circuitry is not powered up. You can confirm this by looking at the LED near the barrel power connector. Two possible workarounds, supply external power at the barrel connector and move the jumper on J1 to position 1-2. OR do what I did and short R353 to bypass the power switch (U31).
  2. After you get power to the RT1064 then J-Link can see the RT1064 processor, unfortunately the version of J-Link loaded into the LPC4322 doesn’t know how to interface with a M7 and then gives up.

 

We need a version of the file Firmware_JLink_LPC-Link2_20160923.bin to make the board work with J-Link (just looking at the date on the file is one hint why it doesn’t work for a M7).

 

I figured out how to restore the board to the original CIMSIS-DAP bootloader using the program_CMSIS.cmd and the boot loader file from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA#MIMXRT1060-EVK

C:> program_CMSIS.cmd lpc4322_bl_crc_20180810.bin

 

When you plug in the board it comes as MAINTENANCE. You can then copy lpc4322__mimxrt1064_evk_if_crc_20180810.bin to the MAINTENANCE drive, the board happily reboots and comes up as RT1064-EVK, however if you power down the board and power it back up again, it reverts to MAINTENANCE if you don’t remove R353. Removing R353 brought everything back to factory settings.

 

I’ll give the patch and your instructions a try tomorrow.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Tuesday, April 9, 2019 3:01 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [EXT] RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I’m not sure yet what’s going on with the J-Link firmware on this board – the USB CDC enumerates but the J-Link commander fails to connect to the RT1064 target. The LPC-Link2 J-Link firmware works fine on the LPCXpresso54114 board. I have been using an external J-Link probe with RT1064.

 

Another route you can try is to restore the DAPLink firmware and use pyOCD instead of J-Link host tools. I hadn’t thought to look for it until now, but it turns out that pyOCD has a generic “cortex_m” target similar to J-Link’s generic “Cortex-M7” target:

https://github.com/zephyrproject-rtos/zephyr/pull/15307

 

With this patch, you can use “west debug -r pyocd” to load internal SRAM-based applications (CONFIG_CODE_ITCM=y, CONFIG_DATA_DTCM=y). You can also build a flash-based application, load it by drag-and-drop to the RT1064-EVK USB mass storage device, and attach a debugger with “west attach -r pyocd”.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Tuesday, April 9, 2019 10:55 AM
To: Lawrence King <lawrence.king@...>; Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: [EXT] RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.

 

Continuing:

 

I Installed the LPCScript utilities on both Ubuntu, and Windows from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab

 

According to the Zephyr instructions here: https://docs.zephyrproject.org/latest/guides/debugging/probes.html#lpclink2-jlink-onboard-debug-probe  Run the script /usr/local/lpcscrypt-2.1.0_842/scripts/program_JLINK

This prints dots for quite some time and eventually fails. 

 

I then used the Windows version of program_JLINK.cmd and it quickly and correctly programs the JLINK software onto the board. Now when I plug in the RT1064 board I see “SEGGER J-Link” in the USB devices.

 

Everything looks OK when I try to debug the program, but gdb fails to connect to J-Link.

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cat ../prj.conf

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cmake -GNinja -DSTLINK_FW=jlink ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.7", minimum required is "3.4")

-- Selected BOARD mimxrt1064_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.7", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk_defconfig as base

Merging /home/lawrence/workspace/rc-demo/RT1064/prj.conf

Configuration written to '/home/lawrence/workspace/rc-demo/RT1064/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

-- The C compiler identification is GNU 8.3.0

-- The CXX compiler identification is GNU 8.3.0

-- The ASM compiler identification is GNU

-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Performing Test toolchain_is_ok

-- Performing Test toolchain_is_ok - Success

Including module: tinycbor in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor

-- Configuring done

-- Generating done

CMake Warning:

  Manually-specified variables were not used by the project:

 

    STLINK_FW

 

 

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1064/build

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[1/110] Preparing syscall dependency handling

 

[104/110] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       16140 B       128 KB     12.31%

            SRAM:        6388 B       128 KB      4.87%

        IDT_LIST:          72 B         2 KB      3.52%

[109/110] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.42b Command Line Version

 

JLinkARM.dll V6.42b (DLL compiled Feb  5 2019 17:34:08)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to target.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Monday, April 8, 2019 5:15 PM
To: Lawrence King <lawrence.king@...>; Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Well I have made progress resolving this problem. (but not resolved)

 

It turns out the that LPC4322 chip on the RT1064 board has two sets of firmware in it. 1) the DAPLINK firmware, and 2) LPC-Link2. To change over you need to install a jumper at J42. I found this out by reading here: https://mcuoneclipse.com/2018/12/31/freelink-lpc4322jet100-based-debug-circuit-on-nxp-i-mx-rt1064-evk-board/

 

Once the Jumper and the windows driver from here:  https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpc-link2:OM13054?tab=Design_Tools_Tab it shows up as: LPC based USB Device

 

Next install the LPCScript on the Ubuntu VirtualBox from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab with:

chmod +x lpcscrypt-2.1.0_842.x86_64.deb.bin

sudo ./lpcscrypt-2.1.0_842.x86_64.deb.bin

 

 

That’s as far as I managed to get today. Does Zephyr know how to debug and flash with a LPC-Link2 debugger? Hints say yes based on info here: https://docs.zephyrproject.org/latest/guides/debugging/host-tools.html#jlink-debug-host-tools

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Friday, April 5, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Actually I don’t think mcuxpresso is using JLink, however during the install, mcuxpresso did remove JLink 6.44 and install JLink 6.42. I suspect this is due to the fact that the ide can work with many debuggers.

 

It appears to be using something called redlinksrv to do debugging. I can see redlinksrv and crt_emu_cm_redlink  in the ‘ps -aux’ output while my blinky is running on the RT1064 board

 

Unfortunately I do not have an external JLink probe that I can use.

 

 

The NXP documentation claims that Zephyr is supported by the board, and there seems to be a lot of RT1064 specific code in the Zephyr tree. How have you been testing Zephyr on the RT1064 board?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Friday, April 5, 2019 3:28 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To:
Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: [EXT] RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

Maureen Helm
 

Hi Lawrence,

I’m not sure yet what’s going on with the J-Link firmware on this board – the USB CDC enumerates but the J-Link commander fails to connect to the RT1064 target. The LPC-Link2 J-Link firmware works fine on the LPCXpresso54114 board. I have been using an external J-Link probe with RT1064.

 

Another route you can try is to restore the DAPLink firmware and use pyOCD instead of J-Link host tools. I hadn’t thought to look for it until now, but it turns out that pyOCD has a generic “cortex_m” target similar to J-Link’s generic “Cortex-M7” target:

https://github.com/zephyrproject-rtos/zephyr/pull/15307

 

With this patch, you can use “west debug -r pyocd” to load internal SRAM-based applications (CONFIG_CODE_ITCM=y, CONFIG_DATA_DTCM=y). You can also build a flash-based application, load it by drag-and-drop to the RT1064-EVK USB mass storage device, and attach a debugger with “west attach -r pyocd”.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Tuesday, April 9, 2019 10:55 AM
To: Lawrence King <lawrence.king@...>; Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: [EXT] RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.

 

Continuing:

 

I Installed the LPCScript utilities on both Ubuntu, and Windows from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab

 

According to the Zephyr instructions here: https://docs.zephyrproject.org/latest/guides/debugging/probes.html#lpclink2-jlink-onboard-debug-probe  Run the script /usr/local/lpcscrypt-2.1.0_842/scripts/program_JLINK

This prints dots for quite some time and eventually fails. 

 

I then used the Windows version of program_JLINK.cmd and it quickly and correctly programs the JLINK software onto the board. Now when I plug in the RT1064 board I see “SEGGER J-Link” in the USB devices.

 

Everything looks OK when I try to debug the program, but gdb fails to connect to J-Link.

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cat ../prj.conf

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cmake -GNinja -DSTLINK_FW=jlink ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.7", minimum required is "3.4")

-- Selected BOARD mimxrt1064_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.7", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk_defconfig as base

Merging /home/lawrence/workspace/rc-demo/RT1064/prj.conf

Configuration written to '/home/lawrence/workspace/rc-demo/RT1064/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

-- The C compiler identification is GNU 8.3.0

-- The CXX compiler identification is GNU 8.3.0

-- The ASM compiler identification is GNU

-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Performing Test toolchain_is_ok

-- Performing Test toolchain_is_ok - Success

Including module: tinycbor in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor

-- Configuring done

-- Generating done

CMake Warning:

  Manually-specified variables were not used by the project:

 

    STLINK_FW

 

 

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1064/build

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[1/110] Preparing syscall dependency handling

 

[104/110] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       16140 B       128 KB     12.31%

            SRAM:        6388 B       128 KB      4.87%

        IDT_LIST:          72 B         2 KB      3.52%

[109/110] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.42b Command Line Version

 

JLinkARM.dll V6.42b (DLL compiled Feb  5 2019 17:34:08)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to target.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Monday, April 8, 2019 5:15 PM
To: Lawrence King <lawrence.king@...>; Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Well I have made progress resolving this problem. (but not resolved)

 

It turns out the that LPC4322 chip on the RT1064 board has two sets of firmware in it. 1) the DAPLINK firmware, and 2) LPC-Link2. To change over you need to install a jumper at J42. I found this out by reading here: https://mcuoneclipse.com/2018/12/31/freelink-lpc4322jet100-based-debug-circuit-on-nxp-i-mx-rt1064-evk-board/

 

Once the Jumper and the windows driver from here:  https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpc-link2:OM13054?tab=Design_Tools_Tab it shows up as: LPC based USB Device

 

Next install the LPCScript on the Ubuntu VirtualBox from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab with:

chmod +x lpcscrypt-2.1.0_842.x86_64.deb.bin

sudo ./lpcscrypt-2.1.0_842.x86_64.deb.bin

 

 

That’s as far as I managed to get today. Does Zephyr know how to debug and flash with a LPC-Link2 debugger? Hints say yes based on info here: https://docs.zephyrproject.org/latest/guides/debugging/host-tools.html#jlink-debug-host-tools

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Friday, April 5, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Actually I don’t think mcuxpresso is using JLink, however during the install, mcuxpresso did remove JLink 6.44 and install JLink 6.42. I suspect this is due to the fact that the ide can work with many debuggers.

 

It appears to be using something called redlinksrv to do debugging. I can see redlinksrv and crt_emu_cm_redlink  in the ‘ps -aux’ output while my blinky is running on the RT1064 board

 

Unfortunately I do not have an external JLink probe that I can use.

 

 

The NXP documentation claims that Zephyr is supported by the board, and there seems to be a lot of RT1064 specific code in the Zephyr tree. How have you been testing Zephyr on the RT1064 board?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Friday, April 5, 2019 3:28 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To:
Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: mcuboot for nrf52840_pca10059

Bolivar, Marti
 

Hi,

 

The tinycbor code was moved to its own repository. You need to run ‘west update’ in your zephyr west installation to get the code.

 

For details on west, please see https://docs.zephyrproject.org/latest/guides/west/repo-tool.html

 

Thanks,

Marti

 

 

From: users@... <users@...> On Behalf Of via Lists.Zephyrproject.Org
Sent: Tuesday, April 9, 2019 10:25 AM
To: users@...
Cc: users@...
Subject: [Zephyr-users] mcuboot for nrf52840_pca10059

 

Hi,

I am trying to compile mcuboot (latest version from git) with zephyr v1.14.0-rc3. I am getting this error:

mcuboot/boot/boot_serial/src/boot_serial.c:36:10: fatal error: cbor.h: No such file or directory

Can someone help me resolving this?

Rgds,
Venkat.


Re: BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

Johan Hedberg
 

On 9 Apr 2019, at 19.15, Johan Hedberg <johan.hedberg@intel.com> wrote:
Actually, I think I missed the fact in the earlier emails that this was specifically about the health server and not just any model publishing. The health server is a special case and does support periodic publishing. It’ll set its own update callback in health_srv.c (health_pub_update function), i.e. that would override anything your application sets if you were to try it. So the main thing you were probably missing with your earlier code was the message buffer for the publication message.
For the record, I found a minor bug with the bt_mesh_fault_update() API in that it wasn’t properly updating the publication message before sending it. I’ve submitted a PR (one-line patch) to fix this:

https://github.com/zephyrproject-rtos/zephyr/pull/15301

Johan


mcuboot for nrf52840_pca10059

Venkat Rao Vallapaneni <vallapaneni@...>
 

Hi,

I am trying to compile mcuboot (latest version from git) with zephyr v1.14.0-rc3. I am getting this error:

mcuboot/boot/boot_serial/src/boot_serial.c:36:10: fatal error: cbor.h: No such file or directory

Can someone help me resolving this?

Rgds,
Venkat.


Re: BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

Johan Hedberg
 

Hi Billy,

On 9 Apr 2019, at 18.16, William Fish <William.fish@manulytica.com> wrote:
I have looked into the health_svr.h and found that the “helper” does not have an update callback. Maybe in might be worth adding to allow periodic updates. I will change my app to use the generic define rather than the “helper”

/** @def BT_MESH_HEALTH_PUB_DEFINE
*
* A helper to define a health publication context
*
* @param _name Name given to the publication context variable.
* @param _max_faults Maximum number of faults the element can have.
*/
#define BT_MESH_HEALTH_PUB_DEFINE(_name, _max_faults) \
BT_MESH_MODEL_PUB_DEFINE(_name, NULL, (1 + 3 + (_max_faults)))
Actually, I think I missed the fact in the earlier emails that this was specifically about the health server and not just any model publishing. The health server is a special case and does support periodic publishing. It’ll set its own update callback in health_srv.c (health_pub_update function), i.e. that would override anything your application sets if you were to try it. So the main thing you were probably missing with your earlier code was the message buffer for the publication message.

Johan


Re: NXP RT1064 board and JLink Debugging

Lawrence King
 

Continuing:

 

I Installed the LPCScript utilities on both Ubuntu, and Windows from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab

 

According to the Zephyr instructions here: https://docs.zephyrproject.org/latest/guides/debugging/probes.html#lpclink2-jlink-onboard-debug-probe  Run the script /usr/local/lpcscrypt-2.1.0_842/scripts/program_JLINK

This prints dots for quite some time and eventually fails. 

 

I then used the Windows version of program_JLINK.cmd and it quickly and correctly programs the JLINK software onto the board. Now when I plug in the RT1064 board I see “SEGGER J-Link” in the USB devices.

 

Everything looks OK when I try to debug the program, but gdb fails to connect to J-Link.

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cat ../prj.conf

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

lawrence@VM:~/workspace/rc-demo/RT1064/build$ cmake -GNinja -DSTLINK_FW=jlink ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.7", minimum required is "3.4")

-- Selected BOARD mimxrt1064_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.7", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1064_evk/mimxrt1064_evk_defconfig as base

Merging /home/lawrence/workspace/rc-demo/RT1064/prj.conf

Configuration written to '/home/lawrence/workspace/rc-demo/RT1064/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

-- The C compiler identification is GNU 8.3.0

-- The CXX compiler identification is GNU 8.3.0

-- The ASM compiler identification is GNU

-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Performing Test toolchain_is_ok

-- Performing Test toolchain_is_ok - Success

Including module: tinycbor in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor

-- Configuring done

-- Generating done

CMake Warning:

  Manually-specified variables were not used by the project:

 

    STLINK_FW

 

 

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1064/build

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[1/110] Preparing syscall dependency handling

 

[104/110] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       16140 B       128 KB     12.31%

            SRAM:        6388 B       128 KB      4.87%

        IDT_LIST:          72 B         2 KB      3.52%

[109/110] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.42b Command Line Version

 

JLinkARM.dll V6.42b (DLL compiled Feb  5 2019 17:34:08)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to target.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Monday, April 8, 2019 5:15 PM
To: Lawrence King <lawrence.king@...>; Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Well I have made progress resolving this problem. (but not resolved)

 

It turns out the that LPC4322 chip on the RT1064 board has two sets of firmware in it. 1) the DAPLINK firmware, and 2) LPC-Link2. To change over you need to install a jumper at J42. I found this out by reading here: https://mcuoneclipse.com/2018/12/31/freelink-lpc4322jet100-based-debug-circuit-on-nxp-i-mx-rt1064-evk-board/

 

Once the Jumper and the windows driver from here:  https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpc-link2:OM13054?tab=Design_Tools_Tab it shows up as: LPC based USB Device

 

Next install the LPCScript on the Ubuntu VirtualBox from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab with:

chmod +x lpcscrypt-2.1.0_842.x86_64.deb.bin

sudo ./lpcscrypt-2.1.0_842.x86_64.deb.bin

 

 

That’s as far as I managed to get today. Does Zephyr know how to debug and flash with a LPC-Link2 debugger? Hints say yes based on info here: https://docs.zephyrproject.org/latest/guides/debugging/host-tools.html#jlink-debug-host-tools

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Friday, April 5, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Actually I don’t think mcuxpresso is using JLink, however during the install, mcuxpresso did remove JLink 6.44 and install JLink 6.42. I suspect this is due to the fact that the ide can work with many debuggers.

 

It appears to be using something called redlinksrv to do debugging. I can see redlinksrv and crt_emu_cm_redlink  in the ‘ps -aux’ output while my blinky is running on the RT1064 board

 

Unfortunately I do not have an external JLink probe that I can use.

 

 

The NXP documentation claims that Zephyr is supported by the board, and there seems to be a lot of RT1064 specific code in the Zephyr tree. How have you been testing Zephyr on the RT1064 board?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Friday, April 5, 2019 3:28 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To:
Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

William Fish
 

I have looked into the health_svr.h  and found that the “helper” does not have an update callback. Maybe in might be worth adding to allow periodic updates. I will change my app to use the generic define rather than the “helper”

 

/** @def BT_MESH_HEALTH_PUB_DEFINE

*

*  A helper to define a health publication context

*

*  @param _name Name given to the publication context variable.

*  @param _max_faults Maximum number of faults the element can have.

*/

#define BT_MESH_HEALTH_PUB_DEFINE(_name, _max_faults) \

    BT_MESH_MODEL_PUB_DEFINE(_name, NULL, (1 + 3 + (_max_faults)))

 

 

From: William Fish
Sent: 09 April 2019 12:57
To: Hedberg, Johan
Cc: users@...
Subject: RE: [Zephyr-users] BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

 

Johan,

Fantastic, thanks.

 

  1. I am using the  BT_SETTINGS and calling settings_load(). I use this as a short cut for development purposes.
  2. The Update callback well spotted many thanks.
  3. The lack of message (pub->msg) creation was why I was so confused

 

Thanks for the advice/input I’ll get busy fixing these.

 

 

From: Hedberg, Johan
Sent: 09 April 2019 12:48
To: William Fish
Cc: users@...
Subject: Re: [Zephyr-users] BT Mesh Health Server Fault PeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

 

Hi Billy,

 

(added zephyr-users back to CC - please don’t drop it since others may benefit from this information as well)

 

On 9 Apr 2019, at 14.28, William Fish <william.fish@...> wrote:

>     /* Health SVR: publish periodicaly to a remote address */

>     struct bt_mesh_cfg_mod_pub health_svr_pub = {

>         .addr = GROUP_ADDR, /*GROUP_ADDR or Node addr */

>         .app_idx = app_idx,

>         .ttl = 0x07,

>         .period = HEALTH_SVR_UPDATE_PERIOD,

>         .transmit=BT_MESH_TRANSMIT(1, 20),

>     };

 

There are a many problems with the above:

 

1. The model publication is expected to be configured by a configuration client - not statically like this. If everything else is initialised correctly (it’s not - see my other points) it *might* work if you’re also using BT_SETTINGS and calling settings_load() from your application, but I’ve never tested it.

 

2. You’re missing an update callback. This is mandatory for periodic publication.

 

3. You’re missing a pub->msg where the publication message is expected to be encoded by your app.

 

The two last issues will likely cause unexpected behaviour and faults. If you had asserts enabled than issue 2 should trigger an assert (see access.c line 216).

 

In general, it’s recommended to use the BT_MESH_MODEL_PUB_DEFINE() macro for defining the publication context.

 

Johan

 

 

 


Virus-free. www.avg.com


Re: BT Mesh Health Server Fault PeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

William Fish
 

Johan,

Fantastic, thanks.

 

  1. I am using the  BT_SETTINGS and calling settings_load(). I use this as a short cut for development purposes.
  2. The Update callback well spotted many thanks.
  3. The lack of message (pub->msg) creation was why I was so confused

 

Thanks for the advice/input I’ll get busy fixing these.

 

 

From: Hedberg, Johan
Sent: 09 April 2019 12:48
To: William Fish
Cc: users@...
Subject: Re: [Zephyr-users] BT Mesh Health Server Fault PeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

 

Hi Billy,

 

(added zephyr-users back to CC - please don’t drop it since others may benefit from this information as well)

 

On 9 Apr 2019, at 14.28, William Fish <william.fish@...> wrote:

>     /* Health SVR: publish periodicaly to a remote address */

>     struct bt_mesh_cfg_mod_pub health_svr_pub = {

>         .addr = GROUP_ADDR, /*GROUP_ADDR or Node addr */

>         .app_idx = app_idx,

>         .ttl = 0x07,

>         .period = HEALTH_SVR_UPDATE_PERIOD,

>         .transmit=BT_MESH_TRANSMIT(1, 20),

>     };

 

There are a many problems with the above:

 

1. The model publication is expected to be configured by a configuration client - not statically like this. If everything else is initialised correctly (it’s not - see my other points) it *might* work if you’re also using BT_SETTINGS and calling settings_load() from your application, but I’ve never tested it.

 

2. You’re missing an update callback. This is mandatory for periodic publication.

 

3. You’re missing a pub->msg where the publication message is expected to be encoded by your app.

 

The two last issues will likely cause unexpected behaviour and faults. If you had asserts enabled than issue 2 should trigger an assert (see access.c line 216).

 

In general, it’s recommended to use the BT_MESH_MODEL_PUB_DEFINE() macro for defining the publication context.

 

Johan

 

 


Virus-free. www.avg.com


Re: BT Mesh Health Server Fault Periodic Publication#bluetoothmesh #zephyrbluetoothmesh

Johan Hedberg
 

Hi Billy,

(added zephyr-users back to CC - please don’t drop it since others may benefit from this information as well)

On 9 Apr 2019, at 14.28, William Fish <william.fish@manulytica.com> wrote:
/* Health SVR: publish periodicaly to a remote address */
struct bt_mesh_cfg_mod_pub health_svr_pub = {
.addr = GROUP_ADDR, /*GROUP_ADDR or Node addr */
.app_idx = app_idx,
.ttl = 0x07,
.period = HEALTH_SVR_UPDATE_PERIOD,
.transmit=BT_MESH_TRANSMIT(1, 20),
};
There are a many problems with the above:

1. The model publication is expected to be configured by a configuration client - not statically like this. If everything else is initialised correctly (it’s not - see my other points) it *might* work if you’re also using BT_SETTINGS and calling settings_load() from your application, but I’ve never tested it.

2. You’re missing an update callback. This is mandatory for periodic publication.

3. You’re missing a pub->msg where the publication message is expected to be encoded by your app.

The two last issues will likely cause unexpected behaviour and faults. If you had asserts enabled than issue 2 should trigger an assert (see access.c line 216).

In general, it’s recommended to use the BT_MESH_MODEL_PUB_DEFINE() macro for defining the publication context.

Johan


Re: BT Mesh Health Server Fault Periodic Publication #zephyrbluetoothmesh #bluetoothmesh

Johan Hedberg
 

Hi Billy,

On 9 Apr 2019, at 13.37, William Fish <William.fish@manulytica.com> wrote:
Have a unusual issue i cant get to the bottom of, I am attempting to implement a Mesh Health Server yet I seem to have come across some odd behaviour.

If i set a publication period for the Health Server Model yet it does not send periodic messages until the number of faults is 8 or more. I am at a loss as to what could be causing this, help please.

It should be working even with a single fault, and this has e.g. been tested with the PTS which does configure periodic publishing during some of its test cases. Is your source code available somewhere? I could take a look to see if I spot something wrong with your code.

Johan


BT Mesh Health Server Fault Periodic Publication #zephyrbluetoothmesh #bluetoothmesh

William Fish
 

Hi All,
Have a unusual issue i cant get to the bottom of, I am attempting to implement a Mesh Health Server yet I seem to have come across some odd behaviour.

If i set a publication period for the Health Server Model yet it does not send periodic messages until the number of faults is 8 or more. I am at a loss as to what could be causing this, help please.

Billy.. 


Re: BlueZ PHY CODED scan via HCI UART on nRF52840_pca10056 #ble #nrf52840 #uart #hci

Piotr Barszczewski <piotr@...>
 

Is there anything else I could check to make it work?


Re: NXP RT1064 board and JLink Debugging

Lawrence King
 

Well I have made progress resolving this problem. (but not resolved)

 

It turns out the that LPC4322 chip on the RT1064 board has two sets of firmware in it. 1) the DAPLINK firmware, and 2) LPC-Link2. To change over you need to install a jumper at J42. I found this out by reading here: https://mcuoneclipse.com/2018/12/31/freelink-lpc4322jet100-based-debug-circuit-on-nxp-i-mx-rt1064-evk-board/

 

Once the Jumper and the windows driver from here:  https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpc-link2:OM13054?tab=Design_Tools_Tab it shows up as: LPC based USB Device

 

Next install the LPCScript on the Ubuntu VirtualBox from here: https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/lpc-microcontroller-utilities/lpcscrypt-v2.1.0:LPCSCRYPT?tab=Design_Tools_Tab with:

chmod +x lpcscrypt-2.1.0_842.x86_64.deb.bin

sudo ./lpcscrypt-2.1.0_842.x86_64.deb.bin

 

 

That’s as far as I managed to get today. Does Zephyr know how to debug and flash with a LPC-Link2 debugger? Hints say yes based on info here: https://docs.zephyrproject.org/latest/guides/debugging/host-tools.html#jlink-debug-host-tools

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Friday, April 5, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Actually I don’t think mcuxpresso is using JLink, however during the install, mcuxpresso did remove JLink 6.44 and install JLink 6.42. I suspect this is due to the fact that the ide can work with many debuggers.

 

It appears to be using something called redlinksrv to do debugging. I can see redlinksrv and crt_emu_cm_redlink  in the ‘ps -aux’ output while my blinky is running on the RT1064 board

 

Unfortunately I do not have an external JLink probe that I can use.

 

 

The NXP documentation claims that Zephyr is supported by the board, and there seems to be a lot of RT1064 specific code in the Zephyr tree. How have you been testing Zephyr on the RT1064 board?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Friday, April 5, 2019 3:28 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To:
Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: onoff-app board sample not working #bluetoothmesh #nrf52832

Johan Hedberg
 

Hi Alexander,

On 7 Apr 2019, at 2.02, alexander.2003@live.com wrote:
[00:00:00.011,352] <err> settings: set-value failure. key: bt error(-2)
I don’t know if this is the cause of your issue, but it implies that you have something in flash (the storage partition) that the application doesn’t expect. Before investigating further I’d suggest trying to erase the entire flash and then reflashing your app.

Johan


onoff-app board sample not working #bluetoothmesh #nrf52832

alexander.2003@...
 

Trying to get the Bluetooth mesh onoff-app sample working on a nrf52_pca10040 it compiles and runs on the board but when it try to provision it using the meshctl tool it freezes and I cant type after I tried using the nrf mesh app to provision but that didn't work either their is a error in the debug feed but it appears to be non-blocking.

[00:00:00.007,446] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.007,446] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.007,446] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 1.14 Build 0
[00:00:00.008,880] <wrn> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.011,352] <err> settings: set-value failure. key: bt error(-2)
[00:00:00.011,596] <inf> bt_hci_core: Identity: d1:7e:0d:1d:8a:19 (random)
[00:00:00.011,596] <inf> bt_hci_core: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[00:00:00.011,596] <inf> bt_hci_core: LMP: version 5.0 (0x09) subver 0xffff
[00:00:00.011,688] <inf> bt_mesh_main: Device UUID: 00000000-0000-0000-0000-d17e0d1d8a19
[00:00:00.608,367] <dbg> bt_mesh_prov.pub_key_ready: Local public key ready


Re: NXP RT1064 board and JLink Debugging

Lawrence King
 

Hi Maureen:

 

Actually I don’t think mcuxpresso is using JLink, however during the install, mcuxpresso did remove JLink 6.44 and install JLink 6.42. I suspect this is due to the fact that the ide can work with many debuggers.

 

It appears to be using something called redlinksrv to do debugging. I can see redlinksrv and crt_emu_cm_redlink  in the ‘ps -aux’ output while my blinky is running on the RT1064 board

 

Unfortunately I do not have an external JLink probe that I can use.

 

 

The NXP documentation claims that Zephyr is supported by the board, and there seems to be a lot of RT1064 specific code in the Zephyr tree. How have you been testing Zephyr on the RT1064 board?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Friday, April 5, 2019 3:28 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To:
Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: NXP RT1064 board and JLink Debugging

Maureen Helm
 

Hi Lawrence,

You’re right, I forgot that RT1064-EVK has a different onboard debug circuit than RT1050-EVK. Do you have an external JLink probe you can use?

 

Are you sure you’re using the JLink GDB server in MCUXpresso IDE? It doesn’t make sense with the DAPLink firmware.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 4:43 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Maureen:

 

Yes, I added the two configs, and I am only trying “ninja debug”. I did try using OpenSDA from https://www.segger.com/downloads/jlink/OpenSDA_V2_1 unfortunately it will not load onto the RT1064 board, it always fails, and leaves a message in the mass storage device that it has timed out. I think there are two reasons for this 1) the RT1064 board does not use a k20 processor for the debugger, it uses a lpc4322 microcontroller, and 2) I think the image needs to be signed, or at least have a valid crc (hence the “crc” in the bin file nameHere is what I see after copying OpenSDA_V2_1.bin to the maintenance drive. The contents of fail.txt says “The transfer timed out.”

 

 

 

I have tried all of the following bin files with no joy:

49_OpenSDA_MIMXRT1050-EVK-Hyperflash.bin

K20dx_mimxrt1064_qspi_if_crc.bin

OpenSDA_V2_1.bn

Open_SDA_V3_2.bin

 

The JLink gdb Server works fine with the lpc4322__mimxrt1064_evk_if_crc_20180810.bin firmware when called from the Xpresso IDE.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Maureen Helm
Sent: Thursday, April 4, 2019 5:11 PM
To: Lawrence King <lawrence.king@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

You have to use JLink firmware to use the JLink GDB server. “lpc4322__mimxrt1064_evk_if_crc_20180810.bin” is DAPLink firmware, not JLink firmware. Try https://www.segger.com/downloads/jlink/OpenSDA_V2_1 instead. Note that this firmware does not enumerate a USB mass storage device.

 

Did you reconfigure your Zephyr application to link into internal SRAM? To do this, add the following to your prj.conf file:

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

This configuration will not work with ‘ninja flash’, you can only use ‘ninja debug’.

 

I don’t think your VM is a problem. I use virtual box all the time.

 

Maureen

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Thursday, April 4, 2019 1:02 PM
To: Maureen Helm <maureen.helm@...>; antoine@...; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Thank you Maureen and Antoine

 

Finally back to this problem.  I tried loading several different bin files to the board while in Maintenance mode, most generate and timeout error and don’t successfully load. The only bin file I could successfully load was “lpc4322__mimxrt1064_evk_if_crc_20180810.bin”. When I restart the board it comes up as RT1064-EVK as expected. When I readout the DETAILS.TXT file I get:

 

# DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 02320000070bfcdd00000000000000000000000097969905

HIC ID: 97969905

Auto Reset: 0

Automation allowed: 0

Overflow detection: 0

Daplink Mode: Interface

Interface Version: 0246

Bootloader Version: 0244

Git SHA: 475c6729c42c688ae33af3af4ea4dbbfe1c35351

Local Mods: 1

USB Interfaces: MSD, CDC, HID, WebUSB

Bootloader CRC: 0xe493996b

Interface CRC: 0x3eb53105

Remount count: 0

 

This all seems reasonable. I loaded the JLinkexe from the Segger site (apt-get didn’t work for me) and it seems to have no problem finding the board. Finally when I run “ninja flash” I get the following output:

 

lawrence@VM:~/workspace/rc-demo/RT1064/build$ ninja debug

[0/1] Debugging mimxrt1064_evk

Using runner: jlink

J-Link GDB server running on port 2331

SEGGER J-Link GDB Server V6.44d Command Line Version

 

JLinkARM.dll V6.44d (DLL compiled Mar 27 2019 17:11:41)

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      yes

Generate logfile:              off

Verify download:               off

Init regs on start:            off

Silent mode:                   on

Single run mode:               on

Target connection timeout:     0 ms

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MIMXRT1064

Target interface:              SWD

Target interface speed:        auto

Target endian:                 little

 

GNU gdb (crosstool-NG 1.24.0-rc2-dirty) 8.2.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

 

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/lawrence/workspace/rc-demo/RT1064/build/zephyr/zephyr.elf...done.

Could not connect to J-Link.

Please check power, connection and settings.:2331: Connection timed out.

"monitor" command not supported by this target.

"monitor" command not supported by this target.

You can't do that when your target is `exec'

(gdb)

 

The Segger gdb server seems to start up, but gdb doesn’t find it. Does this have something to do with the fact that I am running on a virtual machine (Ubuntu under VirtualBox under Win10), I don’t think this is the problem, I didn’t have any problems with NRF or ST boards running Zephyr.

 

I did try changing board.cmake to "--device=Cortex-M7", the messages from JLink are slightly different, but the gdb timeout result is the same. Of course “ninja flash” fails.

 

Any ideas what I should try next? Any other information I can supply?

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Maureen Helm <maureen.helm@...>
Sent: Monday, April 1, 2019 12:39 PM
To: antoine@...; Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

I rewrote the “Programming and Debugging” sections for all the NXP boards in a PR that was just merged on Friday:

https://github.com/zephyrproject-rtos/zephyr/pull/14000

 

For many of the i.MX RT boards I recommend using an external J-Link probe. Only RT1020 and RT1050 have J-Link OpenSDA firmware capable of programming the Hyperflash/QSPI. As Lawrence said, you could use the generic firmware, but you will need to 1) configure your zephyr application to link into internal SRAM (set CONFIG_CODE_ITCM=y and CONFIG_DATA_DTCM=y) and 2) override the Jlink device argument in board.cmake to "--device=Cortex-M7"

 

Maureen

 

From: users@... [mailto:users@...] On Behalf Of Antoine Zen-Ruffinen via Lists.Zephyrproject.Org
Sent: Monday, April 1, 2019 2:20 AM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Hi Lawrence,

 

I've been trough that too. It seems that two things are missing on your side. First, you need to install the J-Link tools on your development host. Secondly, you should swap the "OpenSDA" firmware of the debug adapter MCU (U23 on the borad) to enable support for JLink. The default OpenSDA firmware support the CIMSIS-DAP that is supported by OpenOCD for instance. But OpenOCD is not able to program the i.MXRT familly for now (It is still good for RAM runs). 

 

To install the J-Link tools, if you are under Ubuntu Linux, you could just run "sudo apt install jlink". It's what I did and it do the job. Else, you have to manually download and install it from https://www.segger.com/downloads/jlink/. That should provide you the "JLinkExe" command that is missing in your logs.

 

The "SEGGER" OpenSDA firmware can be downloaded from https://www.segger.com/downloads/jlink/#JLinkOpenSDAGenericFirmwares. Unfortunately it seems that Segger has not released  firmware specific to the RT1064 eval board yet. I would try the one for the "MIMXRT1050-EVK-Hyperflash" as the chip are very similar from the memory point of view. How to change the firmware is explained in the board user guide, but in short:

 

1) Unplug USB.

2) Press&hold SW4 (reset, near debug USB).

3) Replug USB and hold SW4 for 1 or more seconds.

4) A new drive must show up in your host, named "MAINTENANCE"

5) Drag& drop the new firmware to that firmware. After a short programming time, the board shows up as "SEGGER" in the "lsusb" command.

 

You can revert to the original FW in the same way. The Original FW can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/kinetis-developer-resources/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?&tid=vanOpenSDA.

 

If you can still not program the board, check that you have the right rights for the USB device. That can requires to setup the proper udev daemon rule. If you install JLink form unbunt repository, that should be already set.

 

Hope it helps!

 

Regards,

 

Antoine


From: users@... <users@...> on behalf of Lawrence King <lawrence.king@...>
Sent: Saturday, March 30, 2019 4:21:25 AM
To: Zephyr-users@...
Subject: [Zephyr-users] NXP RT1064 board and JLink Debugging

 

Dear All

 

On my business trip last week I was handed a i.MX RT1064 board, so today I tried to build and install the blinky progam for it. Unfortunately I am having problem getting Ninja flash or ninja debug to run.

 

When I started building at the cmake step I discovered my tools were out of date (zephyr-sdk-0.9.5-setup.run instead of zephyr-sdk-0.10.0-setup.run) no problem download the right tools and install them. Then my west install was out of date, again no problem, ‘west update’. Unfortunately it looks like I don’t have JLink support installed. What do I need to do to get that?

 

Curiously, when I look at the attached USB devices it says my board is ‘ARM DAPLink CIMSIS-DAP [0100]’ which is the same as my nrf52xx boards which run just fine with pyocd. Do I have a i.MX board with a ‘newer’ debugger that is ARM standard, or possibly the people that handed me the board updated it?

 

Of course I haven’t go to the step where the blinky program actually runs…

 

FYI - Here is the error message I get when I try ‘ninja flash’:

 

[0/1] Re-running CMake...

Zephyr version: 1.14.0

-- Selected BOARD mimxrt1060_evk

-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.5.6", minimum required is "0.5.6")

-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/mimxrt1060_evk/mimxrt1060_evk.dts as base

-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts

Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig

Loading /home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config as base

Configuration written to '/home/lawrence/workspace/rc-demo/RT1060/build/zephyr/.config'

-- Cache files will be written to: /home/lawrence/.cache/zephyr

Including module(s): tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/lawrence/workspace/rc-demo/RT1060/build

[99/105] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:       24332 B         8 MB      0.29%

            SRAM:        6388 B        32 MB      0.02%

        IDT_LIST:          72 B         2 KB      3.52%

[104/105] Flashing mimxrt1060_evk

Using runner: jlink

Flashing Target Device

Traceback (most recent call last):

  File "/home/lawrence/.local/bin/west", line 11, in <module>

    sys.exit(main())

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 479, in main

    wrap(wrap_argv)

  File "/home/lawrence/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 465, in wrap

    west.main.main(argv)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 576, in main

    args.handler(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/main.py", line 331, in ext_command_handler

    command.run(*west_parser.parse_known_args(argv))

  File "/home/lawrence/workspace/rc-demo/zephyr/.west/west/src/west/commands/command.py", line 85, in run

    self.do_run(args, unknown)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/flash.py", line 32, in do_run

    'ZEPHYR_BOARD_FLASH_RUNNER')

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

    runner.run(command_name)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 407, in run

    self.do_run(command, **kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 99, in do_run

    self.flash(**kwargs)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/jlink.py", line 150, in flash

    self.check_call(cmd)

  File "/home/lawrence/workspace/rc-demo/zephyr/zephyr/scripts/west_commands/runners/core.py", line 466, in check_call

    subprocess.check_call(cmd)

  File "/usr/lib/python3.6/subprocess.py", line 286, in check_call

    retcode = call(*popenargs, **kwargs)

  File "/usr/lib/python3.6/subprocess.py", line 267, in call

    with Popen(*popenargs, **kwargs) as p:

  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__

    restore_signals, start_new_session)

  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child

    raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'JLinkExe': 'JLinkExe'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/lawrence/workspace/rc-demo/RT1060/build && /usr/local/bin/cmake -E env /home/lawrence/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: BlueZ PHY CODED scan via HCI UART on nRF52840_pca10056 #ble #nrf52840 #uart #hci

Marc Herbert
 


On 5 Apr 2019, at 01:57, piotr@... wrote:

[Edited Message Follows]
[Reason: Formatting changes after being able to post back to my own thread instead of private reply which is the only available through web interface]

There's a "Group Reply" button in the bottom right-corner. It took me while to find because you can see it only *after* clicking "Reply", that's an unusual interface.





1261 - 1280 of 2656