---

The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

Lawrence King <lawrence.king@irdeto.com> writes:

Hi Marti:

Thanks for your help.

Sure thing!

I had stopped using the zephyr-sdk because I was bisecting the kernel to find a problem, depending on where I was I needed 0.10.0, 0.10.1, 0.10.2 or 0.10.3 versions of the SDK to compile, however when I was using gnuarmemb it worked around this annoyance for me.

I removed openocd (and autoremoved the assorted packages) and installed SDK 0.10.3 into /opt/zephyr-sdk. I also set 'export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk' in my bashrc and started a new shell. Quick check and openocd is gone from my path.

The west build went cleanly, and now I have a new error from openocd:

lawrence@VM:~/workspace/rc-demo/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-00992-g3333261df-dirty (2019-08-16-00:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS

^^ judging from this, my guess is you need some udev rules to make the
USB device accessible to your user.

Marti

Error: open failed


ERROR: command exited with status 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/stm32f746g_disco/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown


This is 'better' than the missing files, but I still haven't successfully flashed the blinky program onto the Nucleo board. Anything else I missed?

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@nordicsemi.no>
Sent: Tuesday, November 5, 2019 4:55 PM
To: Lawrence King <lawrence.king@irdeto.com>; Zephyr-users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] OpenOCD on STM32 boards

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@lists.zephyrproject.org> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd

It's not always wise to trust in your distro's openocd. It has been hard to get support patches merged into upstream openocd, so the downstream version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks

Use the openocd in the Zephyr SDK. You can do this even if you're not using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR points at a Zephyr SDK install, the build system will use its host tools (like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.

Hi Marti:

Thanks for your help.

I had stopped using the zephyr-sdk because I was bisecting the kernel to find a problem, depending on where I was I needed 0.10.0, 0.10.1, 0.10.2 or 0.10.3 versions of the SDK to compile, however when I was using gnuarmemb it worked around this annoyance for me.

I removed openocd (and autoremoved the assorted packages) and installed SDK 0.10.3 into /opt/zephyr-sdk. I also set 'export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk' in my bashrc and started a new shell. Quick check and openocd is gone from my path.

The west build went cleanly, and now I have a new error from openocd:

lawrence@VM:~/workspace/rc-demo/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-00992-g3333261df-dirty (2019-08-16-00:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed


ERROR: command exited with status 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/stm32f746g_disco/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown


This is 'better' than the missing files, but I still haven't successfully flashed the blinky program onto the Nucleo board. Anything else I missed?

Lawrence King
Principal Developer
+1(416)627-7302

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@lists.zephyrproject.org> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd

It's not always wise to trust in your distro's openocd. It has been hard
to get support patches merged into upstream openocd, so the downstream
version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks

Use the openocd in the Zephyr SDK. You can do this even if you're not
using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR
points at a Zephyr SDK install, the build system will use its host tools
(like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.

Hi all,

This week we will look at GPIO:

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Hi,

On Mon, Nov 04, 2019 at 02:06:04PM -0800, nanjunneo@gmail.com wrote:

Is it compulsory to add the node "virtualcom" to configure a USB virtual
com port via USB-OTG-HS for STM32F407 under Zephyr 2.0.99?

I got the following code in DTS from a partner but it cannot be built
properly. Error indicates that virtualcom does not have necessary
properties. (It is said that the code was compiled in version 1.13.0.)
.......
    usb_cdc: virtualcom {
        label = "CDC_ACM";
    };

You can just remove virtualcom stuff,
samples/subsys/usb/console/prj.conf should assign right console with:

CONFIG_UART_CONSOLE_ON_DEV_NAME="CDC_ACM_0"

Best regards
Andrei Emeltchenko

    chosen {
        zephyr,console = &usb_cdc;
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
        zephyr,ccm = &ccm0;
    };
.......
......
&usbotg_hs {
    status = "ok";
};

Moreover, the sample code (usb/console) only requires to add configure
entries to defconfig so that I got confused. Thanks for your reply in
advance!
_._,_._,_

Is it compulsory to add the node "virtualcom" to configure a USB virtual com port via USB-OTG-HS for STM32F407 under Zephyr 2.0.99?

I got the following code in DTS from a partner but it cannot be built properly. Error indicates that virtualcom does not have necessary properties. (It is said that the code was compiled in version 1.13.0.)
.......
    usb_cdc: virtualcom {
        label = "CDC_ACM";
    };

    chosen {
        zephyr,console = &usb_cdc;
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
        zephyr,ccm = &ccm0;
    };
.......
......
&usbotg_hs {
    status = "ok";
};

Moreover, the sample code (usb/console) only requires to add configure entries to defconfig so that I got confused. Thanks for your reply in advance!

All I did was to uncheck the "start pyOCD locally"

Tried to run gptp with the following results - 
rajas-imac:zephyr rdsingh$ west build -b sam_e70_xplained samples/net/gptp --pristinefdfadfadfad

Zephyr version: 2.0.99

-- Found PythonInterp: /Users/rdsingh/.pyenv/versions/3.7.0/bin/python (found suitable version "3.7.0", minimum required is "3.4") 

-- Selected BOARD sam_e70_xplained

-- Found west: /Users/rdsingh/.pyenv/versions/3.7.0/bin/west (found suitable version "0.6.3", minimum required is "0.6.0")

-- Loading /Users/rdsingh/zephyrDev/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam_e70_xplained.dts as base

-- Overlaying /Users/rdsingh/zephyrDev/zephyrproject/zephyr/dts/common/common.dts

Devicetree configuration written to /Users/rdsingh/zephyrDev/zephyrproject/zephyr/build/zephyr/include/generated/generated_dts_board.conf

 

warning: ETH_SAM_GMAC_MAC0 (defined at drivers/ethernet/Kconfig.sam_gmac:97) was assigned the value

'0xFC' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC0.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC1 (defined at drivers/ethernet/Kconfig.sam_gmac:102) was assigned the value

'0xC2' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC1.html (which is

updated regularly from the master branch). See the 'Setting configuration values'Parsing Kconfig tree in /Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/Kconfig

Loaded configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam_e70_xplained_defconfig'

Merged configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/prj.conf'

Merged configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/boards/sam_e70_xplained.conf'

Configuration saved to '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/build/zephyr/.config'

 section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC2 (defined at drivers/ethernet/Kconfig.sam_gmac:107) was assigned the value

'0x3D' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC2.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC3 (defined at drivers/ethernet/Kconfig.sam_gmac:112) was assigned the value

'0xBC' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC3.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC4 (defined at drivers/ethernet/Kconfig.sam_gmac:117) was assigned the value

'0x8C' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC4.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC5 (defined at drivers/ethernet/Kconfig.sam_gmac:122) was assigned the value

'0xAE' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC5.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but

got the value 'n'. You can check symbol information (including dependencies) in the 'menuconfig'

interface (see the Application Development Primer section of the manual), or in the Kconfig

reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

-- The C compiler identification is GNU 6.3.1

-- The CXX compiler identification is GNU 6.3.1

-- The ASM compiler identification is GNU

-- Found assembler: /Users/rdsingh/arm-none-eabi/bin/arm-none-eabi-gcc

-- Cache files will be written to: /Users/rdsingh/Library/Caches/zephyr

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/rdsingh/zephyrDev/zephyrproject/zephyr/build

-- west build: building application

[1/177] Preparing syscall dependency handling

 

[172/177] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:      148200 B         2 MB      7.07%

            SRAM:       59352 B       384 KB     15.09%

        IDT_LIST:          72 B         2 KB      3.52%

[177/177] Linking C executable zephyr/zephyr.elf

rajas-imac:zephyr rdsingh$ west flash

Connected a serial Terminal to the board -
uart:~$ uart:~$


Then in a Linux machine got AVnu/ptp, compiled and ran - 
~/gptp/build$ sudo ./gptp enp3s0 -F gptp_cfg.ini
INFO : GPTP [17:55:35:130] gPTP starting
INFO : GPTP [17:55:35:132] priority1 = 248
INFO : GPTP [17:55:35:132] announceReceiptTimeout: 3
INFO : GPTP [17:55:35:132] syncReceiptTimeout: 3
INFO : GPTP [17:55:35:132] LINKSPEED_100MB - PHY delay
TX: 1044 | RX: 2133
INFO : GPTP [17:55:35:132] LINKSPEED_1G - PHY delay
TX: 184 | RX: 382
INFO : GPTP [17:55:35:132] neighborPropDelayThresh: 10000
INFO : GPTP [17:55:35:132] syncReceiptThreshold: 8
INFO : GPTP [17:55:35:132] SyncFollowUp with negative correction field: forbidden
ERROR : GPTP [17:55:35:132] Failed to configure timestamping: Operation not supported
ERROR : GPTP [17:55:35:132] post_init failed

ERROR : GPTP [17:55:35:132] failed to initialize port

Any help is much appreciated. I am trying to get at least a dhcpV4_client running without any luck so far.

I am not very experienced with Zephyr. But I am experienced in compiling Linux on embedded systems using buildroot.

I am experienced on Networking and the concepts.

I would like to know how the hardware configuration is done on KConfig in zephyr. Please point me to documentation on that.

best regards,
RDS

Jukka,
After clicking on Reply, I realized it is sent to you and not to the group. Please accept my apologies.

regards,

RDS

Hi all,

This week we will look at:

- V4Z: Update on comments, merge if there is no objections
- https://github.com/zephyrproject-rtos/zephyr/pull/17194

- EEPROM API proposal
- https://github.com/zephyrproject-rtos/zephyr/pull/19972

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Hi,

I have been using sam-e70 with some of the samples, mainly gptp and
echo-server. There have been regressions in past with the networking
samples as currently we have no automatic testing of these samples. The
situation will improve with this PR
https://github.com/zephyrproject-rtos/zephyr/pull/19677 after it is
merged.

If you find some sample that does not work with sam-e70, please file an
issue (one / sample please) for those. All the generic samples that can
be run on Etherhet should work with sam-e70 board.

Cheers,
Jukka

Hi all,
Wondering if SAME70 XPLD board has been tested with Ethernet Networking Samples in the repository. 
So far, all the examples that I have tried did not work for me.
Wondering if I am missing something here.

regards,
RDS

https://github.com/zephyrproject-rtos/zephyr/issues/19244

More discussions on this issue here: https://github.com/zephyrproject-rtos/zephyr/issues/19244