Date   

Re: gptp example project

Jukka Rissanen
 

Hi Kay Li,

the documentation seems to be wrong. The prj_base.conf was renamed to
prj.conf in commit 4e5300ba7f30a21862f68c2e4e2b651f1189d84a
So just do

cmake -GNinja -DBOARD=sam_e70_xplained ..

and the compilation should succeed.

I will send a patch that fixes the doc.

Cheers,
Jukka

On Thu, 2019-05-23 at 09:37 +0800, KAY LI NG wrote:
Hi,

I would like to ask if this gptp example project is possible to run
on windows?

I run this code.

# On Windows
cd %ZEPHYR_BASE%\samples\net\gptp
mkdir build & cd build
cmake -GNinja -DBOARD=sam_e70_xplained -DCONF_FILE=prj_base.conf ..

but this error occur.
Zephyr version: 1.14.0
-- Selected BOARD sam_e70_xplained
-- Found west: C:/Python37/Scripts/west.exe (found suitable version
"0.5.6", minimum required is "0.5.4")
-- Loading
C:/Users/kayling/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam
_e70_xplained.dts as base
-- Overlaying
C:/Users/kayling/zephyrproject/zephyr//dts/common/common.dts
CMake Error at
C:/Users/kayling/zephyrproject/zephyr/cmake/kconfig.cmake:132
(message):
File not found:

C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/prj_base.conf
Call Stack (most recent call first):

C:/Users/kayling/zephyrproject/zephyr/cmake/app/boilerplate.cmake:397
(include)
CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!
See also
"C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFi
les/CMakeOutput.log".
See also
"C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFi
les/CMakeError.log".
Whats the problem with this? i didnt modify anything from the example
code.

Regards,
Kay Li


Re: Closing an accepting BSD socket from a different thread

Stephan Gatzka
 

Hello Paul!

Thanks for the answer.

Paradigmatically correct approach to this situation is:
1. Avoid sharing I/O resources (not just sockets) across different
threads.
2. If/when you can't avoid it, you need to synchronize access to those
resources from different threads using synchronization primitives
(mutexes, semaphores, etc.)
Sure, no doubt on that. The problem is, that I need a mechanism to "unblock" the accept.
Yes, I could use non-blocking sockets with poll(), but I also found no easy to use mechanism to "unblock" poll(). I can't just send a signal to that thread which called poll() like it would work in Linux.



Eventually, we'll need to catch and fix such cases. But the only
visible effect for well-behaving applications following the guidelines
above will be bloating code size in the Zephyr network stack/socket
implementation (so hopefully, we won't get bad community stereotypes
due to that). If you have a small reproduction testcase for the issue,
definitely please submit it at
https://github.com/zephyrproject-rtos/zephyr/issues
Will do.

My question is how I can safely "unblock" the thread waiting in the
zsock_accept()?
A way to not block forever in accept() call is to use timed poll() on
that socket. The thread issuing the poll() call would be the best
party to know when to close this socket (e.g., if there's no
activity during some period of time). Other threads could signal the
owner thread that they want something to be done to the socket via flag
variables. E.g., following is a well-know pattern:
=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();
=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources. That I really don't like, especially an small battery powered systems.

No, the only possible solution I see is an additional socket connection via localhost which "signals" poll() and afterwards I can see what needs to be done (e.g. calling close()).

The reason for my question is that I need to implement an event loop based system. I need events for sockets, timers, DNS.
The idea is to use e zephyr message queue with a thread reading from the queue and calling the callback functions.

Regards,
Stephan


Re: Zephyr compatible motes for 802.15.4

Andrei
 

Hi Nikos,

I have not developed 802.15.4, and those answer are only my IMOs.

On Wed, May 22, 2019 at 05:10:25PM +0300, Nikos Karamolegkos wrote:
Thank you Andrei,
1) Therefore these module can support 802.15.4 in 2.4 GHz band only.
Correct?
Yes

2) Can I use them to run zigbee or 802.15.4g (SUN) in 2.4GHz with zephyr.
Does zephyr supports SUN and zigbee?
No

3) Is there any special code and device for the 802.15.4 GW?
You can make Zephyr board behave like "serial-radio" device and use
Contiki native border router, etc samples.
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/wpan_serial

Best regards
Andrei Emeltchenko


Re: Closing an accepting BSD socket from a different thread

Paul Sokolovsky
 

Hello Stephan,

On Wed, 22 May 2019 16:10:19 +0200
"Stephan Gatzka" <stephan.gatzka@...> wrote:

Hello!

I've a thread blocking on an zsock_accept(). After a certain time
another thread decides that this socket is no longer required and
calls zsock_close() on that socket.
Paradigmatically correct approach to this situation is:

1. Avoid sharing I/O resources (not just sockets) across different
threads.
2. If/when you can't avoid it, you need to synchronize access to those
resources from different threads using synchronization primitives
(mutexes, semaphores, etc.)

Now the thread blocking on
zsock_accept() crashes horribly deep down in zephyrs socket
implementation.
Eventually, we'll need to catch and fix such cases. But the only
visible effect for well-behaving applications following the guidelines
above will be bloating code size in the Zephyr network stack/socket
implementation (so hopefully, we won't get bad community stereotypes
due to that). If you have a small reproduction testcase for the issue,
definitely please submit it at
https://github.com/zephyrproject-rtos/zephyr/issues

My question is how I can safely "unblock" the thread waiting in the
zsock_accept()?
A way to not block forever in accept() call is to use timed poll() on
that socket. The thread issuing the poll() call would be the best
party to know when to close this socket (e.g., if there's no
activity during some period of time). Other threads could signal the
owner thread that they want something to be done to the socket via flag
variables. E.g., following is a well-know pattern:

=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();

=== other threads ===
should_exit = true;


Thanks,
Stephan
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


gptp example project

KAY LI NG <kayli0109@...>
 

Hi,

I would like to ask if this gptp example project is possible to run on windows?

I run this code.

# On Windows
cd %ZEPHYR_BASE%\samples\net\gptp
mkdir build & cd build
cmake -GNinja -DBOARD=sam_e70_xplained -DCONF_FILE=prj_base.conf ..

but this error occur.
Zephyr version: 1.14.0
-- Selected BOARD sam_e70_xplained
-- Found west: C:/Python37/Scripts/west.exe (found suitable version "0.5.6", minimum required is "0.5.4")
-- Loading C:/Users/kayling/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam_e70_xplained.dts as base
-- Overlaying C:/Users/kayling/zephyrproject/zephyr//dts/common/common.dts
CMake Error at C:/Users/kayling/zephyrproject/zephyr/cmake/kconfig.cmake:132 (message):
  File not found:
  C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/prj_base.conf
Call Stack (most recent call first):
  C:/Users/kayling/zephyrproject/zephyr/cmake/app/boilerplate.cmake:397 (include)
  CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!
See also "C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFiles/CMakeError.log".
Whats the problem with this? i didnt modify anything from the example code.

Regards,
Kay Li


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Adam Mooers
 

I was able to get DFU working by itself. See the prj.conf and flashing method of this thread (but remove the bluetooth flags because BT HCI will cause problems with DFU in Zephyr 1.14):

https://lists.zephyrproject.org/g/users/topic/31634625

Basically, you need to enable the DFU driver, the flash driver, and the DFU manager. 

Also be sure to follow this read me for setting up MCUboot:

https://github.com/JuulLabs-OSS/mcuboot/blob/master/ext/nrf/README.md

I was unable to get MCUboot 1.3 working on the nRF52840, but master (2dc9f8f) worked.


Re: #ble #nrf52480 Issue with enabling DFU and BLE USB HCI simultaneously #nrf52480 #ble

Adam Mooers
 

I created a Github issue for the above incompatibility:

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

It looks like DFU cannot be used at the same time as Bluetooth HCI in v1.14 or master but there is active development on composite USB.


Closing an accepting BSD socket from a different thread

Stephan Gatzka
 

Hello!

I've a thread blocking on an zsock_accept(). After a certain time another thread decides that this socket is no longer required and calls zsock_close() on that socket. Now the thread blocking on zsock_accept() crashes horribly deep down in zephyrs socket implementation.

My question is how I can safely "unblock" the thread waiting in the zsock_accept()?

Thanks,
Stephan


Re: Zephyr compatible motes for 802.15.4

Nikos Karamolegkos
 

Thank you Andrei,
1) Therefore these module can support 802.15.4 in 2.4 GHz band only. Correct?
2) Can I use them to run zigbee or 802.15.4g (SUN) in 2.4GHz with zephyr. Does zephyr supports SUN and zigbee?
3) Is there any special code and device for the 802.15.4 GW?

Greetings,

On 5/14/19 4:10 PM, Andrei Emeltchenko wrote:
Hi,

On Tue, May 14, 2019 at 03:49:49PM +0300, Nikos Karamolegkos wrote:
Hello all,

I have seen that Zephyr supports a lot of MCU boards. I was wondering if
there is any mote supported by Zephyr that includes the MCU board and the RF
module of the 802.15.4. For example in Contiki there is the Zolertia
RE-Mote. I have not find anything.
reel_board, frdm_k64f + CR20A, quark_se_devboard, the easiest is
reel_board: https://www.zephyrproject.org/introducing-the-zephyr-reel-board/

Best regards
Andrei Emeltchenko
--
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Does zephyr supports DTLS and 6lowpan

Michael Scott
 

Hello Nikos,

On Wed, May 22, 2019, 6:11 AM Nikos Karamolegkos <nkaram@...> wrote:

Hello all,

As I can see here, zephyr supports DTLS via mbed DTLS. However,  according this "LWM2M OMA Lightweight Machine-to-Machine Protocol (V1.0 Feb 2017) is supported via the “Register Device” API (Register, De-Register and Update) and has template implementations for Security, Server, Device Management and Firmware objects. DTLS and Bootstrap support are currently not supported. LwM2M client implements the library as an example."


That documentation is out of date.  The LwM2M subsystem supports both DTLS and Bootstrap mode.

I opened a new issue to correct that bit of documentation:

what is the truth?

Also, does zephyr supports 6lowpan? I have not seen anything


Yes, as a matter of fact the following sample documentation for the LwM2M client discuss the DTLS and BLE/6lowpan support:

This is the protocol / subsystem documentation for LwM2M which can also be helpful:

- Mike

Thank you,

-- 
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Does zephyr supports DTLS and 6lowpan

Nikos Karamolegkos
 

Hello all,

As I can see here, zephyr supports DTLS via mbed DTLS. However,  according this "LWM2M OMA Lightweight Machine-to-Machine Protocol (V1.0 Feb 2017) is supported via the “Register Device” API (Register, De-Register and Update) and has template implementations for Security, Server, Device Management and Firmware objects. DTLS and Bootstrap support are currently not supported. LwM2M client implements the library as an example."

what is the truth?

Also, does zephyr supports 6lowpan? I have not seen anything

Thank you,

-- 
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: NVS corrupt after applying sys_reboot() directly after nvs_write() #nrf52840

Phil Hipp
 

Alright, I fixed that issue by splitting the predefined flash storage partition (storage_partition) in the board's dts in half. Leaving the name of the first one as is and naming the second one storage_partition_nvs. I now have following layout:

- storage_partiton - size 0x2000 - used by FCB.
- storage_partiton_nvs - size 0x2000 - used by NVS.

Hope this will work.


Re: NVS corrupt after applying sys_reboot() directly after nvs_write() #nrf52840

Phil Hipp
 

I found out that NVS seems to interfere with the settings fcb. I'm using that for the bt settings (pairing keys, etc.). Is there any way to use the settings fcb and NVS concurrently?


NVS corrupt after applying sys_reboot() directly after nvs_write() #nrf52840

Phil Hipp
 

Hi,

in my application, I want to apply a reboot via sys_reboot(SYS_REBOOT_WARM) directly after writing a specific value to NVS via nvs_write() to cleanly reinitialize the system with that value in NVS.

But somehow it seems that the NVS got corrupted by the reboot. When I try to initialize the NVS with nvs_init() after the reboot it always returns -22 (-EINVAL). The error seems to appear in nvs_gc().

Can anybody tell me, what I'm doing wrong here?

 

Best

Philipp


#ble #nrf52480 Issue with enabling DFU and BLE USB HCI simultaneously #nrf52480 #ble

Adam Mooers
 

Whenever the USB DFU driver and the USB BLE HCI driver are both enabled, neither works as expected . BLE HCI over USB works when the DFU USB driver is disabled via prj.conf (CONFIG_USB_DFU_CLASS=n). DFU works when the bluetooth kernel module is removed in Linux (via modprobe btusb).

Are there any known bugs/limitations with the USB stack which would prevent DFU and BLE from operating simultaneously? Alternatively, is it possible that I am missing some settings in dfu-util?

Environment:

    Ubuntu 16.04 (host)
    nRF52840 PCA10056 hw v. 1.1.0
    Zephyr 1.14
    Zephyr SDK 0.10.0
    dfu-util 0.9 (modified for increased timeout during flash erase)

prj.conf:

    CONFIG_STDOUT_CONSOLE=y
    CONFIG_GPIO=y
    CONFIG_SERIAL=y
    CONFIG_UART_INTERRUPT_DRIVEN=y

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

    CONFIG_BT=y
    CONFIG_BT_HCI_RAW=y
    CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
    CONFIG_BT_RX_BUF_LEN=258
    CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

    CONFIG_USB=y
    CONFIG_USB_DEVICE_STACK=y
   
    # Bluetooth works when the below setting is set to no
    CONFIG_USB_DFU_CLASS=y
    CONFIG_USB_DEVICE_BLUETOOTH=y

    CONFIG_FLASH=y
    CONFIG_SOC_FLASH_NRF=y
    CONFIG_BOOTLOADER_MCUBOOT=y
    CONFIG_IMG_MANAGER=y
    CONFIG_MCUBOOT_IMG_MANAGER=y

    CONFIG_USB_DEVICE_VID=0x167f
    CONFIG_USB_DEVICE_PID=0x3001

    CONFIG_USB_DEVICE_MANUFACTURER="Company"
    CONFIG_USB_DEVICE_PRODUCT="Product"
    CONFIG_USB_DEVICE_SN="123abc"

Flashing method:

    source zephyr/zephyr/zephyr-env.sh
    mkdir -p build/nrf52840_pca10056 && cd build/nrf52840_pca10056
    cmake -GNinja -DBOARD=nrf52840_pca10056 -Dapp_VERSION_BUILD=9999 ../..
    ninja
    ~/repos/mcuboot/scripts/imgtool.py sign --key ~/repos/mcuboot/root-ec-p256.pem --header-size 0x200 --align 8 --version 1.2 -S 0x69000 ./zephyr/zephyr.hex signed-hello.hex
    nrfjprog --family NRF52 --program signed-hello.hex --sectorerase
    ~/repos/mcuboot/scripts/imgtool.py sign --key ~/repos/mcuboot/root-ec-p256.pem --header-size 0x200 --align 8 --version 1.2 -S 0x69000 ./zephyr/zephyr.bin signed-hello.bin
    sudo dfu-util --alt 1 --download signed-hello.bin

Output of failed run of dfu-util:

    dfu-util 0.9

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2019 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

    dfu-util: Invalid DFU suffix signature
    dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
    Opening DFU capable USB device...
    ID 167f:3001
    Run-time device DFU version 0110
    Claiming USB DFU Runtime Interface...
    dfu-util: Cannot claim interface 1: LIBUSB_ERROR_BUSY

Output of successful run of dfu-util:

    dfu-util 0.9

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2019 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

    dfu-util: Invalid DFU suffix signature
    dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
    Opening DFU capable USB device...
    ID 167f:3001
    Run-time device DFU version 0110
    Claiming USB DFU Interface...
    Setting Alternate Setting #1 ...
    Determining device status: state = dfuIDLE, status = 0
    dfuIDLE, continuing
    DFU mode device DFU version 0110
    Device returned transfer size 64
    Copying data from PC to DFU device
    Download    [=========================] 100%        85970 bytes
    Download done.
    state(2) = dfuIDLE, status(0) = No error condition is present
    Done!


Re: Zephyr compatible motes for 802.15.4

Andrei
 

Hi,

On Tue, May 14, 2019 at 03:49:49PM +0300, Nikos Karamolegkos wrote:
Hello all,

I have seen that Zephyr supports a lot of MCU boards. I was wondering if
there is any mote supported by Zephyr that includes the MCU board and the RF
module of the 802.15.4. For example in Contiki there is the Zolertia
RE-Mote. I have not find anything.
reel_board, frdm_k64f + CR20A, quark_se_devboard, the easiest is
reel_board: https://www.zephyrproject.org/introducing-the-zephyr-reel-board/

Best regards
Andrei Emeltchenko


Zephyr compatible motes for 802.15.4

Nikos Karamolegkos
 

Hello all,

I have seen that Zephyr supports a lot of MCU boards. I was wondering if there is any mote supported by Zephyr that includes the MCU board and the RF module of the 802.15.4. For example in Contiki there is the Zolertia RE-Mote. I have not find anything.

Thank you,

--
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Need help in interfacing ENC28J60 to PCA10056 #nrf52840 #spi

giriprasad@...
 

Hi,

I am trying to interface ENC28J60 module to PCA10056(NRF52840). Below are my pin configurations:

=================    ===================================
NRF52840 PCA10056    ENC28J60 (pin numbers on the board)
=================    ===================================
P0_19                                     SCK
P0_21                                     SO
P0_20                                     SI
P0_03                                     CS
P0_04                                     INT
VDD                                    VCC
GND                                    GND
=================    ===================================


Also, I had cut and connected proper SBs on board to connect ENC28J60 board. After done with the connections part, configurations are done by using menuconfig in dhcpclient application and flashed the software. As a result, it is observed in the console that an IP Address has been generated for the board. But, when tried to ping to that IP, timeout was occurring. Please help us to solve this issue.

Thanks & Regards,
Giri Prasad N.


Zephyr and LoRaWAN stack

Nikos Karamolegkos <nkaram@...>
 

Hello everyone,

As I can see in the documentation of the zephyr, zephyr supports Dragino LSN50 LoRA Sensor Node. I would like to ask if the code of the LoRaWAN stack is available in the github for this node or should be developed?

Thank you,
Nikos

--
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Dragino LSN50 and STLink

Erwan Gouriou
 

Hi Gustavo,

Sorry, I'm not familiar with Dragino, nor J-Link, maybe Endre would know better, as he did the board port.

Erwan



On Wed, 8 May 2019 at 19:35, Gustavo F N <gustavofn@...> wrote:
Awesome, thanks! 

On Wed, May 8, 2019 at 6:55 AM Kumar Gala <kumar.gala@...> wrote:
Adding 2 people who might be able to help.

- k

> On May 7, 2019, at 1:29 PM, Gustavo FN <gustavofn@...> wrote:
>
> Hello everyone,
>
> I noticed the Dragino LSN50 board has been ported to Zephyr and that's pretty cool.
>
> I have one of this board and following the page https://docs.zephyrproject.org/latest/boards/arm/dragino_lsn50/doc/index.html#flashing-an-application-to-dragino-lsn50 they say 'Connect the Dragino LSN50 to a STLinkV2...'.
>
> Since the the board has no dedicated connect to JTAG/SWD, I read the stm32l072cz datasheet and found out the the SWDIO is PA13 and SWCLK is PA14.
>
> I connected these pins at my J-Link Ultra in the following way:
> JTAG -> LSN50
> pin 6 -> pin GND
> pin 7 -> pin PA13 (SWDIO)
> pin 9 -> pin  PA14
> pin 19 -> pin VDD (+3.3V)
>
> And tried to connect the Ozone but it did not work. At Ozone, in J-Link Settings I have the target device: STM32L072CZ, Target Interface: SWD:auto speed and Host Interface: USB.
>
> If someone knows how to connect the LSN50 board and could explain me I'll be very grateful.
>
> All the best,

1641 - 1660 of 3109