Date   

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

Johan Hedberg
 

Hi Alexander,

On 7 Apr 2019, at 2.02, alexander.2003@... 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.






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

piotr@...
 
Edited

Hello Johan,
 
Thank you for your response. Following your suggestion I've updated my kernel to 4.20 and there is a change in behavior though I don't see LE CODED  scanning to be working + btmgmt behavior is bit odd which I document below:
 
For testing the PHY changes via btmgmt I've ran this script (added #1-9 to later reference them in btmon logs):
 
#!/bin/bash
# This is where my bluez@master is at
HCITOOL=~/tmp/bluez/tools/hcitool
BTMGMT=~/tmp/bluez/tools/btmgmt
 
echo "Set 1M"
${BTMGMT} phy LE1MTX LE1MRX  #1
sleep 1
${BTMGMT} phy #2
 
echo "Set 2M"
${BTMGMT} phy LE2MTX LE2MRX #3
sleep 1
${BTMGMT} phy #4
sleep 1
 
echo "Set Coded"
${BTMGMT} phy LECODEDTX LECODEDRX #5
sleep 1
${BTMGMT} phy #6
sleep 1
 
echo "Set coded manually"
${HCITOOL} cmd 08 32 #7
${HCITOOL} cmd 08 31 03 04 04 &8
sleep 1
echo "Now it's ok"
${BTMGMT} phy #9
 
 
The btmon output is the following (I've added separators for where each command from the script above was called):
 
 
Bluetooth monitor ver 5.50
= Note: Linux version 4.20.0-042000-generic (x86_64)                   0.300394
= Note: Bluetooth subsystem version 2.22                               0.300400
= New Index: 00:00:00:00:00:00 (Primary,UART,hci0)              [hci0] 0.300402
= Open Index: 00:00:00:00:00:00                                 [hci0] 0.300402
= Index Info: 00:00:00:00:00:00 (not assigned)                  [hci0] 0.300403
@ MGMT Open: bluetoothd (privileged) version 1.14             {0x0003} 0.300404
@ MGMT Open: bluetoothd (privileged) version 1.14             {0x0001} 0.300405
@ MGMT Open: btmon (privileged) version 1.14                  {0x0002} 0.300660
 
${BTMGMT} phy LE1MTX LE1MRX #1
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 3.097362
@ MGMT Command: Set PHY Configuration (0x0045) plen 4  {0x0004} [hci0] 3.097470
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3       #1 [hci0] 3.097522
        All PHYs preference: 0x00
        TX PHYs preference: 0x01
          LE 1M
        RX PHYs preference: 0x01
          LE 1M
> HCI Event: Command Complete (0x0e) plen 4                  #2 [hci0] 3.098708
      LE Set Default PHY (0x08|0x0031) ncmd 1
        Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 3         {0x0004} [hci0] 3.098827
      Set PHY Configuration (0x0045) plen 0
        Status: Success (0x00)
@ MGMT Event: PHY Configuration Cha.. (0x0026) plen 4  {0x0002} [hci0] 3.098853
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Event: PHY Configuration Cha.. (0x0026) plen 4  {0x0003} [hci0] 3.098853
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Event: PHY Configuration Cha.. (0x0026) plen 4  {0x0001} [hci0] 3.098853
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Close: btmgmt                                          {0x0004} 3.099048
 
${BTMGMT} phy #2
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 4.104949
@ MGMT Command: Get PHY Configuration (0x0044) plen 0  {0x0004} [hci0] 4.105111
@ MGMT Event: Command Complete (0x0001) plen 15        {0x0004} [hci0] 4.105122
      Get PHY Configuration (0x0044) plen 12
        Status: Success (0x00)
        Supported PHYs: 0x7e00
          LE 1M TX
          LE 1M RX
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Configurable PHYs: 0x7800
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Close: btmgmt                                          {0x0004} 4.105236
 
${BTMGMT} phy LE2MTX LE2MRX #3
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 4.108783
@ MGMT Command: Set PHY Configuration (0x0045) plen 4  {0x0004} [hci0] 4.108954
        Selected PHYs: 0x1800
          LE 2M TX
          LE 2M RX
@ MGMT Event: Command Status (0x0002) plen 3           {0x0004} [hci0] 4.108965
      Set PHY Configuration (0x0045)
        Status: Invalid Parameters (0x0d)
@ MGMT Close: btmgmt                                          {0x0004} 4.109075
 
${BTMGMT} phy #4
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 5.116776
@ MGMT Command: Get PHY Configuration (0x0044) plen 0  {0x0004} [hci0] 5.116920
@ MGMT Event: Command Complete (0x0001) plen 15        {0x0004} [hci0] 5.116931
      Get PHY Configuration (0x0044) plen 12
        Status: Success (0x00)
        Supported PHYs: 0x7e00
          LE 1M TX
          LE 1M RX
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Configurable PHYs: 0x7800
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Close: btmgmt                                          {0x0004} 5.117054
 
${BTMGMT} phy LECODEDTX LECODEDRX #5
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 6.124056
@ MGMT Command: Set PHY Configuration (0x0045) plen 4  {0x0004} [hci0] 6.124241
        Selected PHYs: 0x6000
          LE CODED TX
          LE CODED RX
@ MGMT Event: Command Status (0x0002) plen 3           {0x0004} [hci0] 6.124251
      Set PHY Configuration (0x0045)
        Status: Invalid Parameters (0x0d)
@ MGMT Close: btmgmt                                          {0x0004} 6.124351
 
${BTMGMT} phy #6
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 7.131377
@ MGMT Command: Get PHY Configuration (0x0044) plen 0  {0x0004} [hci0] 7.131551
@ MGMT Event: Command Complete (0x0001) plen 15        {0x0004} [hci0] 7.131561
      Get PHY Configuration (0x0044) plen 12
        Status: Success (0x00)
        Supported PHYs: 0x7e00
          LE 1M TX
          LE 1M RX
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Configurable PHYs: 0x7800
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Selected PHYs: 0x0600
          LE 1M TX
          LE 1M RX
@ MGMT Close: btmgmt                                          {0x0004} 7.131922
@ RAW Open: hcitool (privileged) version 2.22                 {0x0004} 8.138584
@ RAW Close: hcitool                                          {0x0004} 8.138654
@ RAW Open: hcitool (privileged) version 2.22                 {0x0004} 8.138690
@ RAW Close: hcitool                                          {0x0004} 8.138700
 
${HCITOOL} cmd 08 32 #7
 
@ RAW Open: hcitool (privileged) version 2.22          {0x0004} [hci0] 8.138735
< HCI Command: LE Set PHY (0x08|0x0032) plen 0               #3 [hci0] 8.138854
        invalid packet size
> HCI Event: Command Status (0x0f) plen 4                    #4 [hci0] 8.139762
      LE Set PHY (0x08|0x0032) ncmd 1
        Status: Unsupported Feature or Parameter Value (0x11)
@ RAW Close: hcitool                                   {0x0004} [hci0] 8.139915
@ RAW Open: hcitool (privileged) version 2.22                 {0x0004} 8.143334
@ RAW Close: hcitool                                          {0x0004} 8.143388
@ RAW Open: hcitool (privileged) version 2.22                 {0x0004} 8.143425
@ RAW Close: hcitool                                          {0x0004} 8.143436
 
${HCITOOL} cmd 08 31 03 04 04 #8
 
@ RAW Open: hcitool (privileged) version 2.22          {0x0004} [hci0] 8.143472
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3       #5 [hci0] 8.143606
        All PHYs preference: 0x03
          No TX PHY preference
          No RX PHY preference
        TX PHYs preference: 0x04
          LE Coded
        RX PHYs preference: 0x04
          LE Coded
> HCI Event: Command Complete (0x0e) plen 4                  #6 [hci0] 8.144779
      LE Set Default PHY (0x08|0x0031) ncmd 1
        Status: Success (0x00)
@ RAW Close: hcitool                                   {0x0004} [hci0] 8.144922
 
${BTMGMT} phy #9
 
@ MGMT Open: btmgmt (privileged) version 1.14                 {0x0004} 9.151090
@ MGMT Command: Get PHY Configuration (0x0044) plen 0  {0x0004} [hci0] 9.151272
@ MGMT Event: Command Complete (0x0001) plen 15        {0x0004} [hci0] 9.151282
      Get PHY Configuration (0x0044) plen 12
        Status: Success (0x00)
        Supported PHYs: 0x7e00
          LE 1M TX
          LE 1M RX
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Configurable PHYs: 0x7800
          LE 2M TX
          LE 2M RX
          LE CODED TX
          LE CODED RX
        Selected PHYs: 0x6000
          LE CODED TX
          LE CODED RX
@ MGMT Close: btmgmt                                          {0x0004} 9.151400
 
 
 
As you see only operation #8 actually changed the PHY settings as reported by btmgmt. This might have something to do with bluez itself, not sure. I'm ok with using hcitool and sending raw commands via hcitool to change the PHY. The thing is that even after changing the PHY to CODED, when I start LE scan I don't get anything even though I have S=8 CODED advertisers around me which also scan each other. I start scanning just by this command:
 
${HCITOOL} cmd 08 0c 01 01 
 
 
Best regards,
PB


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

Johan Hedberg
 

Hi,

On 3 Apr 2019, at 13.17, piotr@... wrote:
# BT_HCI_OP_READ_LOCAL_EXT_FEATURES BT_OP(BT_OGF_INFO, 0x0004)
$ hcitool cmd 04 04

< HCI Command: Read Local Extended Features (0x04|0x0004) plen 0 #119 [hci0] 865.683100
invalid packet size
HCI Event: Command Complete (0x0e) plen 4 #120 [hci0] 865.684035
Read Local Extended Features (0x04|0x0004) ncmd 1
Status: Unknown HCI Command (0x01)
HCI_Read_Local_Extended_Features is a BR/EDR-only command, which is why you are getting this response from the LE-only controller. You’ll also see that it’s not listed in the supported commands response.

Johan


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

Johan Hedberg
 

Hi,

On 3 Apr 2019, at 13.17, piotr@... wrote:
@ MGMT Command: Set PHY Configuration (0x0045) plen 4
Selected PHYs: 0x6000
LE CODED TX
LE CODED RX
@ MGMT Event: Command Status (0x0002) plen 3
Set PHY Configuration (0x0045)
Status: Unknown Command (0x01)
Notice that these are MGMT commands and events, i.e. just communication between BlueZ user space and the Linux kernel and not directly related to the controller. The Set PHY Configuration MGMT command was introduced in Linux 4.19, so it seems like you may have a too old kernel.

Johan


Re: NXP RT1064 board and JLink Debugging

Lawrence King
 

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 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

Lawrence King
 

Dear All:

 

As a quick check, and to make sure I am not doing anything really dumb, I installed the NXP Xpresso dev system on Ubuntu (instructions here: https://mcuoneclipse.com/2018/12/28/first-steps-with-the-nxp-i-mx-rt1064-evk-board/ ). During the install process the Jlinkexe was rolled from 6.44 back to 6.42 and it is able to access the board, load code, single step, breakpoint, etc with no issues. I did retry ninja debug from the zephyr directory, the messages indicates it is now running 6.42, but no difference in the response. To me it looks like a zephyr script problem starting up gdb.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Thursday, April 4, 2019 2: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 debug” 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

Lawrence King
 

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: [Networking][Mbedtls] Judicious use of cipher suites

Lubos, Robert
 

Hi Karthik,

 

In order to use cryptography you need a cryptographic library. Our networking applications use mbedTLS, therefore I don’t see a way to disable it, while still using cryptographic features.

 

I’m also surprised about what you write about config-tls-generic.h. It does indeed enable some ciphersuites by default (the ones used by our demo apps), but in fact it’s just a small subset of all ciphersuites available in the mbedTLS library. And they all can be disabled through Kconfig, or a proper configuration in your prj.conf file.

Especially that usage of CONFIG_MBEDTLS_USER_CONFIG_FILE indicates that you do use the generic config, perhaps you wanted to use CONFIG_MBEDTLS_CFG_FILE to use a custom one?

 

Regarding your question on limiting ciphersuites, you can do it in two ways:

  1. You can enable only a subset of available ciphersuites through a socket option, just as you noticed (see TLS_CIPHERSUITE_LIST, or tls_config->cipher_list in case of MQTT). This option accepts an array of integers, with IANA assigned ciphersuite identificatiors (see https://github.com/zephyrproject-rtos/zephyr/blob/master/ext/lib/crypto/mbedtls/include/mbedtls/ssl_ciphersuites.h)

Just note, that this configuration is a runtime configuration – all ciphersuites that were configured in your mbedTLS config file, but are not used, are still compiled in your application.

  1. You can specify a list of ciphersuites that should be available in the mbedTLS by specifying MBEDTLS_SSL_CIPHERSUITES config, see https://github.com/zephyrproject-rtos/zephyr/blob/9983710c442186e477e67fe04895a1e2be0609b2/ext/lib/crypto/mbedtls/configs/config-thread.h#L90 for sample use. This option will compile in only the selected cihpersuites.

 

Of course you can combine both approaches, and limit a compile-time number of ciphersuites, and then use different ciphersuites on different TLS contexts (sockets).

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Prabhu Vinod, Karthik via Lists.Zephyrproject.Org
Sent: Thursday, April 4, 2019 07:25
To: users@...
Cc: users@...
Subject: [Zephyr-users] [Networking][Mbedtls] Judicious use of cipher suites

 

Hi

 

I wanted to check if there is a way to use cryptographic cipher suites without including following config options.

 

CONFIG_MBEDTLS=y

CONFIG_MBEDTLS_BUILTIN=y

 

CONFIG_MBEDTLS_ENABLE_HEAP=y

CONFIG_MBEDTLS_HEAP_SIZE=56240

CONFIG_MBEDTLS_USER_CONFIG_ENABLE=y

CONFIG_MBEDTLS_USER_CONFIG_FILE="user-tls.conf"

 

In most user space application clients like those of mqtt, co-ap https etc,  I have observed we associate a tls_config with a socket as a socket_opt. I wanted to know if we could use a very small set of cipher suites just by providing the list of cipher suites in tls_config->cipher_list  and skip enabling the CONFIG_MBEDTLS, CONFIG_MBEDTLS_BUILTIN. I don’t want to use config-tls-generic config file as the default as it contains almost all the cipher suites

 

At Application level we can do the below:

struct mqtt_sec_config *tls_config = &client->transport.tls.config;

 

tls_config->peer_verify = 2;

tls_config->cipher_list = NULL;

tls_config->sec_tag_list = m_sec_tags;

tls_config->sec_tag_count = ARRAY_SIZE(m_sec_tags);

tls_config->hostname = hostname;

 

 

Look forward to some suggestions here

 

 

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.


[Networking][Mbedtls] Judicious use of cipher suites

Prabhu Vinod, Karthik
 

Hi

 

I wanted to check if there is a way to use cryptographic cipher suites without including following config options.

 

CONFIG_MBEDTLS=y

CONFIG_MBEDTLS_BUILTIN=y

 

CONFIG_MBEDTLS_ENABLE_HEAP=y

CONFIG_MBEDTLS_HEAP_SIZE=56240

CONFIG_MBEDTLS_USER_CONFIG_ENABLE=y

CONFIG_MBEDTLS_USER_CONFIG_FILE="user-tls.conf"

 

In most user space application clients like those of mqtt, co-ap https etc,  I have observed we associate a tls_config with a socket as a socket_opt. I wanted to know if we could use a very small set of cipher suites just by providing the list of cipher suites in tls_config->cipher_list  and skip enabling the CONFIG_MBEDTLS, CONFIG_MBEDTLS_BUILTIN. I don’t want to use config-tls-generic config file as the default as it contains almost all the cipher suites

 

At Application level we can do the below:

struct mqtt_sec_config *tls_config = &client->transport.tls.config;

 

tls_config->peer_verify = 2;

tls_config->cipher_list = NULL;

tls_config->sec_tag_list = m_sec_tags;

tls_config->sec_tag_count = ARRAY_SIZE(m_sec_tags);

tls_config->hostname = hostname;

 

 

Look forward to some suggestions here

 

 

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.


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

piotr@...
 
Edited

Hi,

I'm trying to force a nRF52840-pca10056 DK to scan for BLE advertisements with PHY set to CODED via HCI and BlueZ 5.50 but keep getting rejected by the hci_uart from Zephyr examples (master branch). I have few scanners and advertisers written on top of nRF15.3 SDK which work so right now I'm trying to test how PHY_CODED works with HCI.
I might (for sure I am) be doing something wrong but I haven't found any good resources on doing that and was thinking that someone on this mailing list has already solved this problem.

What happens is while sending:

$ hcitool cmd 08 41 00 00 04 

the command is correctly recognized by btmon as 

@ RAW Open: hcitool (privileged) version 2.22                {0x0003} [hci0] 5244.434886
< HCI Command: LE Set Extended Scan Para.. (0x08|0x0041) plen 3  #157 [hci0] 5244.435025
        Own address type: Public (0x00)                                                 
        Filter policy: Accept all advertisement (0x00)                                  
        PHYs: 0x04                                                                      
        Entry 0: LE Coded                                                               
          Type: Reserved (0x02)                                                         
          Interval: 13.750 msec (0x0016)                                                
          Window: 0.625 msec (0x0001)                                                   
> HCI Event: Command Complete (0x0e) plen 4                      #158 [hci0] 5271.619061
      LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1                              
            Status: Unknown HCI Command (0x01)                                     


When debugging with GDB i could not send any breakpoints beyond this function call: https://github.com/zephyrproject-rtos/zephyr/blob/21358baa72cea9c23be57444eb91444774842f97/subsys/bluetooth/controller/hci/hci.c#L2235 - for some reason the debugger never stopped anywhere in  https://github.com/zephyrproject-rtos/zephyr/blob/21358baa72cea9c23be57444eb91444774842f97/subsys/bluetooth/controller/hci/hci.c#L1576 


When looking through hci_uart .hex features list I found nothing suspicious:

                                                                         
# BT_HCI_OP_READ_LOCAL_FEATURES           BT_OP(BT_OGF_INFO, 0x0003) 
$ hcitool cmd 04 03                                                          

< HCI Command: Read Local Supported Featu.. (0x04|0x0003) plen 0  #115 [hci0] 865.674540 
> HCI Event: Command Complete (0x0e) plen 12                      #116 [hci0] 865.675121 
      Read Local Supported Features (0x04|0x0003) ncmd 1                                 
        Status: Success (0x00)                                                           
        Features: 0x00 0x00 0x00 0x00 0x60 0x00 0x00 0x00                                
          BR/EDR Not Supported                                                           
          LE Supported (Controller)                                                      


# BT_HCI_OP_READ_SUPPORTED_COMMANDS       BT_OP(BT_OGF_INFO, 0x0002) 
$ hcitool cmd 04 02                                                          
 

< HCI Command: Read Local Supported Comma.. (0x04|0x0002) plen 0  #117 [hci0] 865.679037 
> HCI Event: Command Complete (0x0e) plen 68                      #118 [hci0] 865.680251 
      Read Local Supported Commands (0x04|0x0002) ncmd 1                                 
        Status: Success (0x00)                                                           
        Commands: 65 entries                                                             
          Disconnect (Octet 0 - Bit 5)                                                   
          Read Remote Version Information (Octet 2 - Bit 7)                              
          Set Event Mask (Octet 5 - Bit 6)                                               
          Reset (Octet 5 - Bit 7)                                                        
          Read Transmit Power Level (Octet 10 - Bit 2)                                   
          Set Controller To Host Flow Control (Octet 10 - Bit 5)                         
          Host Buffer Size (Octet 10 - Bit 6)                                            
          Host Number of Completed Packets (Octet 10 - Bit 7)                            
          Read Local Version Information (Octet 14 - Bit 3)                              
          Read Local Supported Features (Octet 14 - Bit 5)                               
          Read BD ADDR (Octet 15 - Bit 1)                                                
          Set Event Mask Page 2 (Octet 22 - Bit 2)                                       
          LE Set Event Mask (Octet 25 - Bit 0)                                           
          LE Read Buffer Size (Octet 25 - Bit 1)                                         
          LE Read Local Supported Features (Octet 25 - Bit 2)                            
          LE Set Random Address (Octet 25 - Bit 4)                                       
          LE Set Advertising Parameters (Octet 25 - Bit 5)                               
          LE Read Advertising Channel TX Power (Octet 25 - Bit 6)                        
          LE Set Advertising Data (Octet 25 - Bit 7)                                     
          LE Set Scan Response Data (Octet 26 - Bit 0)                                   
          LE Set Advertise Enable (Octet 26 - Bit 1)                                     
          LE Set Scan Parameters (Octet 26 - Bit 2)                                      
          LE Set Scan Enable (Octet 26 - Bit 3)                                          
          LE Create Connection (Octet 26 - Bit 4)                                        
          LE Create Connection Cancel (Octet 26 - Bit 5)                                 
          LE Read White List Size (Octet 26 - Bit 6)                                     
          LE Clear White List (Octet 26 - Bit 7)                                         
          LE Add Device To White List (Octet 27 - Bit 0)                                 
          LE Remove Device From White List (Octet 27 - Bit 1)                            
          LE Connection Update (Octet 27 - Bit 2)                                        
          LE Set Host Channel Classification (Octet 27 - Bit 3)                          
          LE Read Channel Map (Octet 27 - Bit 4)                                         
          LE Read Remote Used Features (Octet 27 - Bit 5)                                
          LE Encrypt (Octet 27 - Bit 6)                                                  
          LE Rand (Octet 27 - Bit 7)                                                     
          LE Start Encryption (Octet 28 - Bit 0)                                         
          LE Long Term Key Request Reply (Octet 28 - Bit 1)                              
          LE Long Term Key Request Neg Reply (Octet 28 - Bit 2)                          
          LE Read Supported States (Octet 28 - Bit 3)                                    
          LE Receiver Test (Octet 28 - Bit 4)                                            
          LE Transmitter Test (Octet 28 - Bit 5)                                         
          LE Test End (Octet 28 - Bit 6)                                                 
          Read Authenticated Payload Timeout (Octet 32 - Bit 4)                          
          Write Authenticated Payload Timeout (Octet 32 - Bit 5)                         
          LE Remote Connection Parameter Request Reply (Octet 33 - Bit 4)                
          LE Remote Connection Parameter Request Negative Reply (Octet 33 - Bit 5)       
          LE Set Data Length (Octet 33 - Bit 6)                                          
          LE Read Suggested Default Data Length (Octet 33 - Bit 7)                       
          LE Write Suggested Default Data Length (Octet 34 - Bit 0)                      
          LE Add Device To Resolving List (Octet 34 - Bit 3)                             
          LE Remove Device From Resolving List (Octet 34 - Bit 4)                        
          LE Clear Resolving List (Octet 34 - Bit 5)                                     
          LE Read Resolving List Size (Octet 34 - Bit 6)                                 
          LE Read Peer Resolvable Address (Octet 34 - Bit 7)                             
          LE Read Local Resolvable Address (Octet 35 - Bit 0)                            
          LE Set Address Resolution Enable (Octet 35 - Bit 1)                            
          LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)                   
          LE Read Maximum Data Length (Octet 35 - Bit 3)                                 
          LE Read PHY (Octet 35 - Bit 4)                                                 
          LE Set Default PHY (Octet 35 - Bit 5)                                          
          LE Set PHY (Octet 35 - Bit 6)                                                  
          LE Enhanced Receiver Test (Octet 35 - Bit 7)                                   
          LE Enhanced Transmitter Test (Octet 36 - Bit 0)                                
          LE Read Transmit Power (Octet 38 - Bit 7)                                      
          LE Set Privacy Mode (Octet 39 - Bit 2)                                         


# BT_HCI_OP_READ_LOCAL_EXT_FEATURES       BT_OP(BT_OGF_INFO, 0x0004) 
$ hcitool cmd 04 04                                                          

< HCI Command: Read Local Extended Features (0x04|0x0004) plen 0  #119 [hci0] 865.683100 
        invalid packet size                                                              
> HCI Event: Command Complete (0x0e) plen 4                       #120 [hci0] 865.684035 
      Read Local Extended Features (0x04|0x0004) ncmd 1                                  
        Status: Unknown HCI Command (0x01)                                               





I've wen't over ninja menuconfig options and all config options seem to be set correctly to enable BLE PHY changes, Bluez 5.50 doesn't seem to be the problem because it just passes the bytes back and forth so what else could be the key to enable BLE PHY CODED scanning and advertising in HCI UART example?


------
Update after more attempts.

I've tried this multiple times but can't get to PHY CODED BLE scanning or even any result when trying to change the radio settings. 
I'm on the master branch of Zephyr and Bluez, kernel 4.15 and nRF52840 running hci_uart example also from Zephyr master branch.
Even the btmgmt "phy" command fails when trying to do anything around coding:

@ MGMT Command: Set PHY Configuration (0x0045) plen 4    
        Selected PHYs: 0x6000
          LE CODED TX
          LE CODED RX
@ MGMT Event: Command Status (0x0002) plen 3             
      Set PHY Configuration (0x0045)
        Status: Unknown Command (0x01)


Config for the project is also in line with what I've found in this mailing list:

CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_0_NRF_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=n
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=y
 
CONFIG_BT_CONN=y
CONFIG_BT_CTLR_PHY=y
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_PHY_UPDATE=y
CONFIG_BT_AUTO_PHY_UPDATE=y
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_RX_BUF_LEN=258
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
 

Has anyone ever made this work?


nRF52832 silently stops advertising

Christoph Schramm
 

Dear Group,

 

our device based on BL652 / nRF52832 silently stops advertising. After a reboot, everything works perfectly, but after some hours, it will just stop to be visible for other devices. Log gives no errors.

I even re-start advertising every 5 minutes (which should also fail, I guess). By the way, is there any way to check if the API is still advertising?

 

Anyone experienced this before?

 

Thanks,

Chris


Re: STM32 CAN bus driver issues #stm32 #can

Rodrigo Peixoto <rodrigopex@...>
 

*Root directory = project folder

On Mon, 1 Apr 2019 at 22:27 Rodrigo Peixoto <rodrigopex@...> wrote:
Josef,

The BOARD_ROOT works for me even with Stm32 boards. The pinmux is mandatory for alternate functions on st boards.

You can run the following commad to set the board root:

west build -b hvac_sensors -s. -- -DBOARD_ROOT=`pwd`

The code is considering your board is in the root directory following the structure boards/arm/hvac_sensors.

Done. Your board will run properly, I hope :)

At the dts, some configuration are applied to variables only and not affect the code at all. You'll need to use those variables on your code. If you want to check the dts generated variables, you can see the build/zephyr/include/generated/...

Good luck.
Best regards,
Rodrigo Peixoto
On Sat, 30 Mar 2019 at 11:37 Josef Raschen <josef@...> wrote:
Update: CAN bus is working now with my board. I had to move by board
config into the Zephyr tree, then pinmuxing seems to work. I still do
not know the root cause. My configuration (for CAN) was identical to the
one of the STM32F072B Discovery board in the Zephyr tree, but still
pinmuxing was not working - at least for pins PB8 and PB9 where my CAN
transceiver is connected to. Maybe I missed to set a variable for
out-of-tree board definitions, or maybe there is a bug in the build
scripts for out-of-tree builds. I thought that setting the BOARD_ROOT
variable for CMake should be sufficient. Also the CONFIG_* flags were
all set correctly, just my pinmuxing was ignored.

Anyway, I can live with having my board config in the Zephyr tree.

In case anybody is interested, I pushed everything to github:
https://github.com/JosefR/zephyr (board name: hvac_sensors)

Thank you for all your help,
Josef


On 30.03.19 12:13, Josef Raschen wrote:
> Hi,
>
> the driver is built into the kernel, but what I found out yesterday is,
> that the pinmuxing is not set up correctly. And the STM32 CAN controller
> will wait until it has received some bits before it leaves the init
> mode. So I think, when I fix that, it should work.
>
> Thanks,
> Josef
>
>
> On 30.03.19 04:03, Lawrence King wrote:
>> To me, the problem look more like you didn’t include the CAN bus
>> drivers when you built the kernel. Try running ‘make menuconfig’ and
>> turning on the CAN bus, then rebuilding.
>
>
>
>
>



--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.
--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.


Re: STM32 CAN bus driver issues #stm32 #can

Rodrigo Peixoto <rodrigopex@...>
 

Josef,

The BOARD_ROOT works for me even with Stm32 boards. The pinmux is mandatory for alternate functions on st boards.

You can run the following commad to set the board root:

west build -b hvac_sensors -s. -- -DBOARD_ROOT=`pwd`

The code is considering your board is in the root directory following the structure boards/arm/hvac_sensors.

Done. Your board will run properly, I hope :)

At the dts, some configuration are applied to variables only and not affect the code at all. You'll need to use those variables on your code. If you want to check the dts generated variables, you can see the build/zephyr/include/generated/...

Good luck.
Best regards,
Rodrigo Peixoto

On Sat, 30 Mar 2019 at 11:37 Josef Raschen <josef@...> wrote:
Update: CAN bus is working now with my board. I had to move by board
config into the Zephyr tree, then pinmuxing seems to work. I still do
not know the root cause. My configuration (for CAN) was identical to the
one of the STM32F072B Discovery board in the Zephyr tree, but still
pinmuxing was not working - at least for pins PB8 and PB9 where my CAN
transceiver is connected to. Maybe I missed to set a variable for
out-of-tree board definitions, or maybe there is a bug in the build
scripts for out-of-tree builds. I thought that setting the BOARD_ROOT
variable for CMake should be sufficient. Also the CONFIG_* flags were
all set correctly, just my pinmuxing was ignored.

Anyway, I can live with having my board config in the Zephyr tree.

In case anybody is interested, I pushed everything to github:
https://github.com/JosefR/zephyr (board name: hvac_sensors)

Thank you for all your help,
Josef


On 30.03.19 12:13, Josef Raschen wrote:
> Hi,
>
> the driver is built into the kernel, but what I found out yesterday is,
> that the pinmuxing is not set up correctly. And the STM32 CAN controller
> will wait until it has received some bits before it leaves the init
> mode. So I think, when I fix that, it should work.
>
> Thanks,
> Josef
>
>
> On 30.03.19 04:03, Lawrence King wrote:
>> To me, the problem look more like you didn’t include the CAN bus
>> drivers when you built the kernel. Try running ‘make menuconfig’ and
>> turning on the CAN bus, then rebuilding.
>
>
>
>
>



--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.


Re: NXP RT1064 board and JLink Debugging

Maureen Helm
 

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

Antoine Zen-Ruffinen
 

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.