Date   

Re: SAME70 Xplained failed to build with ethernet networking

Sam Wong
 

I reinstalled zephyr with “west init” and “west update” on July 19th and I just checked. Menuconfig shows the proper range 1-6 for number of RX/TX queues now.

Sorry, no idea why it is correct now. I did reinstalled zephyr at least twice with the same steps couple of weeks ago and getting the same 1-0 range problem.

 

I’m running

Ubuntu 20.04 LTS

SDK 0.11.4.

 

Thanks for checking.

Sam

 

 

From: "users@..." <users@...> on behalf of "nandojve@..." <nandojve@...>
Date: Saturday, July 25, 2020 at 10:24 AM
To: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @sam,

I update my machine with the current main zephyr repo and west update.
Unfortunately I can't see the problem.

 

Environment (please complete the following information):

  • OS: Linux (Debian Buster)
  • Toolchain Zephyr SDK 0.11.3
  • Zephyr     f014ba1ff
  • hal_atmel 1fe96f0a

Could you check the environment and confirm you are at the same hashes?

 

Em sex., 10 de jul. de 2020 às 13:17, Sam Wong <sam@...> escreveu:

I deleted build and ran “west build -b sam_e70b_xplained samples/net/telnet”.

I then ran guiconfig and the active range is still stuck at [1,0] and won’t allow me to select anything and always reverts back to 0.

Here is the output when I ran guiconfig. Warnings at the last two lines.

 

Thanks.

Sam

 

sam@ubuntu:~/zephyr/zephyr$ west build -t guiconfig

-- west build: running target guiconfig

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

Including boilerplate (Zephyr base (cached)): /home/sam/zephyr/zephyr/cmake/app/boilerplate.cmake

-- Application: /home/sam/zephyr/zephyr/samples/net/telnet

-- Zephyr version: 2.3.99 (/home/sam/zephyr/zephyr)

-- Board: sam_e70b_xplained

-- Found toolchain: zephyr (/opt/zephyr-sdk-0.11.4)

-- Found west: /home/sam/.local/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")

-- Found dtc: /opt/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")

-- Found BOARD.dts: /home/sam/zephyr/zephyr/boards/arm/sam_e70_xplained/sam_e70b_xplained.dts

-- Generated zephyr.dts: /home/sam/zephyr/zephyr/build/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /home/sam/zephyr/zephyr/build/zephyr/include/generated/devicetree_unfixed.h

Parsing /home/sam/zephyr/zephyr/Kconfig

Loaded configuration '/home/sam/zephyr/zephyr/boards/arm/sam_e70_xplained/sam_e70b_xplained_defconfig'

Merged configuration '/home/sam/zephyr/zephyr/samples/net/telnet/prj.conf'

Configuration saved to '/home/sam/zephyr/zephyr/build/zephyr/.config'

Kconfig header saved to '/home/sam/zephyr/zephyr/build/zephyr/include/generated/autoconf.h'

 

warning: TEST_RANDOM_GENERATOR (defined at boards/shields/esp_8266/boards/sam4e_xpro.defconfig:17,

subsys/random/Kconfig:8) was assigned the value 'y' but got the value 'n'. Check these unsatisfied

dependencies: ((BOARD_SAM4E_XPRO && NETWORKING && SHIELD_ESP_8266) || !ENTROPY_HAS_DRIVER) (=n). See

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html and/or look

up TEST_RANDOM_GENERATOR in the menuconfig/guiconfig interface. The Application Development Primer,

Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be

helpful too.

 

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

-- Configuring done

-- Generating done

-- Build files have been written to: /home/sam/zephyr/zephyr/build

[0/1] cd /home/sam/zephyr/zephyr/build...fig.py /home/sam/zephyr/zephyr/Kconfig

Traceback (most recent call last):

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 2330, in <module>

    _main()

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 104, in _main

    menuconfig(standard_kconfig(__doc__))

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 238, in menuconfig

    _root.mainloop()

  File "/usr/lib/python3.8/tkinter/__init__.py", line 1420, in mainloop

    self.tk.mainloop(n)

KeyboardInterrupt

Loaded configuration '/home/sam/zephyr/zephyr/build/zephyr/.config'

warning: user value 1 on the int symbol ETH_SAM_GMAC_QUEUES (defined at drivers/ethernet/Kconfig.sam_gmac:21) ignored due to being outside the active range ([1, 0]) -- falling back on defaults

warning: default value 1 on ETH_SAM_GMAC_QUEUES (defined at drivers/ethernet/Kconfig.sam_gmac:21) clamped to 0 due to being outside the active range ([1, 0])

 

From: "users@..." <users@...> on behalf of "nandojve@..." <nandojve@...>
Date: Friday, July 10, 2020 at 8:15 AM
To: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Ok, now we can build let's explore configs.

 

When you add options -p(restine) auto west will decide about prestine configs and that may be the case of [1,0] config.

So it may doesn't apply the default board configuration.

 

In general, I always use this command, without -p

make build -b sam_e70b_xplained <sample>

 

It will create a build dir with default configuration and after that you should have [1,1].

Then you can increase that parameter to enable priority queues. We don't enable all because uses a lot of buffers

and most applications don't need that feature, it saves RAM.

 

BR,

Gerson

 

Em sex., 10 de jul. de 2020 às 11:55, Sam Wong <sam@...> escreveu:

It was my misunderstanding. I thought each board need to have its own folder in boards/arm. I didn’t see a directory boards/arm/sam_e70b_xplained and so never tried to build with sam_e70b_xplained as shown in your first reply.

Instead, I made a sam_e70b_xplained directory out of the files from sam_e70_xplained and got it working. Just now I pulled my folder away and was able to build sam_e70b_xplained just fine 😊.

 

The remaining mystery is that the range is now stuck in [1,0] for both revisions. As I said, I deleted the zephyr folder and did west init and west update. The range was already [1,0] immediately after west update.

I got round that by putting the correct configs in sam_e70b_defconfig so that I don’t need to run menuconfig.

 

Anyway, I got the board working.

Thanks again.

Sam.

 

From: "users@..." <users@...> on behalf of "nandojve@..." <nandojve@...>
Date: Friday, July 10, 2020 at 7:06 AM
To: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Sam Wong,

 

We define two SoC versions at boards/sam_e70_xplained, same for sam_v71_xult:

Version SoC rev A:  sam_e70_xplained

Version SoC rev B:  sam_e70b_xplained

 

> Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

> “Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

> Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

The range [1,3] is for SoC rev A.

 

Make sure you always use version B since your SoC is the last version and you will see range [1,6].

 

BR,

Gerson

 

Em qua., 8 de jul. de 2020 às 23:11, Sam Wong <sam@...> escreveu:

Tried many times. No change, still don’t have sam_e70b_xplained.

I even tried from scratch, ran

 

                West init ~/zephyr

                Cd ~/zephyr

                West update

                Cd zephyr

                West build -p auto -b sam_e70_xplained samples/net/telnet

 

Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

“Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

 

Thanks.

Sam

 

 

 

 

From: Stephanos Ioannidis <root@...>
Date: Wednesday, July 8, 2020 at 5:15 PM
To: Sam Wong <sam@...>, Gerson Fernando Budke <nandojve@...>
Cc: "users@..." <users@...>
Subject: RE: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Have you tried ‘west update’?

 

Stephanos

 

From: users@... <users@...> On Behalf Of Sam Wong via lists.zephyrproject.org
Sent: Thursday, July 9, 2020 7:47 AM
To: Gerson Fernando Budke <nandojve@...>
Cc: users@...
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: SAME70 Xplained failed to build with ethernet networking

nandojve@...
 

Hi @sam,

I update my machine with the current main zephyr repo and west update.
Unfortunately I can't see the problem.

Environment (please complete the following information):

  • OS: Linux (Debian Buster)
  • Toolchain Zephyr SDK 0.11.3
  • Zephyr     f014ba1ff
  • hal_atmel 1fe96f0a
Could you check the environment and confirm you are at the same hashes?

Em sex., 10 de jul. de 2020 às 13:17, Sam Wong <sam@...> escreveu:

I deleted build and ran “west build -b sam_e70b_xplained samples/net/telnet”.

I then ran guiconfig and the active range is still stuck at [1,0] and won’t allow me to select anything and always reverts back to 0.

Here is the output when I ran guiconfig. Warnings at the last two lines.

 

Thanks.

Sam

 

sam@ubuntu:~/zephyr/zephyr$ west build -t guiconfig

-- west build: running target guiconfig

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

Including boilerplate (Zephyr base (cached)): /home/sam/zephyr/zephyr/cmake/app/boilerplate.cmake

-- Application: /home/sam/zephyr/zephyr/samples/net/telnet

-- Zephyr version: 2.3.99 (/home/sam/zephyr/zephyr)

-- Board: sam_e70b_xplained

-- Found toolchain: zephyr (/opt/zephyr-sdk-0.11.4)

-- Found west: /home/sam/.local/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")

-- Found dtc: /opt/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")

-- Found BOARD.dts: /home/sam/zephyr/zephyr/boards/arm/sam_e70_xplained/sam_e70b_xplained.dts

-- Generated zephyr.dts: /home/sam/zephyr/zephyr/build/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /home/sam/zephyr/zephyr/build/zephyr/include/generated/devicetree_unfixed.h

Parsing /home/sam/zephyr/zephyr/Kconfig

Loaded configuration '/home/sam/zephyr/zephyr/boards/arm/sam_e70_xplained/sam_e70b_xplained_defconfig'

Merged configuration '/home/sam/zephyr/zephyr/samples/net/telnet/prj.conf'

Configuration saved to '/home/sam/zephyr/zephyr/build/zephyr/.config'

Kconfig header saved to '/home/sam/zephyr/zephyr/build/zephyr/include/generated/autoconf.h'

 

warning: TEST_RANDOM_GENERATOR (defined at boards/shields/esp_8266/boards/sam4e_xpro.defconfig:17,

subsys/random/Kconfig:8) was assigned the value 'y' but got the value 'n'. Check these unsatisfied

dependencies: ((BOARD_SAM4E_XPRO && NETWORKING && SHIELD_ESP_8266) || !ENTROPY_HAS_DRIVER) (=n). See

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html and/or look

up TEST_RANDOM_GENERATOR in the menuconfig/guiconfig interface. The Application Development Primer,

Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be

helpful too.

 

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

-- Configuring done

-- Generating done

-- Build files have been written to: /home/sam/zephyr/zephyr/build

[0/1] cd /home/sam/zephyr/zephyr/build...fig.py /home/sam/zephyr/zephyr/Kconfig

Traceback (most recent call last):

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 2330, in <module>

    _main()

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 104, in _main

    menuconfig(standard_kconfig(__doc__))

  File "/home/sam/zephyr/zephyr/scripts/kconfig/guiconfig.py", line 238, in menuconfig

    _root.mainloop()

  File "/usr/lib/python3.8/tkinter/__init__.py", line 1420, in mainloop

    self.tk.mainloop(n)

KeyboardInterrupt

Loaded configuration '/home/sam/zephyr/zephyr/build/zephyr/.config'

warning: user value 1 on the int symbol ETH_SAM_GMAC_QUEUES (defined at drivers/ethernet/Kconfig.sam_gmac:21) ignored due to being outside the active range ([1, 0]) -- falling back on defaults

warning: default value 1 on ETH_SAM_GMAC_QUEUES (defined at drivers/ethernet/Kconfig.sam_gmac:21) clamped to 0 due to being outside the active range ([1, 0])

 

From: "users@..." <users@...> on behalf of "nandojve@..." <nandojve@...>
Date: Friday, July 10, 2020 at 8:15 AM
To: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Ok, now we can build let's explore configs.

 

When you add options -p(restine) auto west will decide about prestine configs and that may be the case of [1,0] config.

So it may doesn't apply the default board configuration.

 

In general, I always use this command, without -p

make build -b sam_e70b_xplained <sample>

 

It will create a build dir with default configuration and after that you should have [1,1].

Then you can increase that parameter to enable priority queues. We don't enable all because uses a lot of buffers

and most applications don't need that feature, it saves RAM.

 

BR,

Gerson

 

Em sex., 10 de jul. de 2020 às 11:55, Sam Wong <sam@...> escreveu:

It was my misunderstanding. I thought each board need to have its own folder in boards/arm. I didn’t see a directory boards/arm/sam_e70b_xplained and so never tried to build with sam_e70b_xplained as shown in your first reply.

Instead, I made a sam_e70b_xplained directory out of the files from sam_e70_xplained and got it working. Just now I pulled my folder away and was able to build sam_e70b_xplained just fine 😊.

 

The remaining mystery is that the range is now stuck in [1,0] for both revisions. As I said, I deleted the zephyr folder and did west init and west update. The range was already [1,0] immediately after west update.

I got round that by putting the correct configs in sam_e70b_defconfig so that I don’t need to run menuconfig.

 

Anyway, I got the board working.

Thanks again.

Sam.

 

From: "users@..." <users@...> on behalf of "nandojve@..." <nandojve@...>
Date: Friday, July 10, 2020 at 7:06 AM
To: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Sam Wong,

 

We define two SoC versions at boards/sam_e70_xplained, same for sam_v71_xult:

Version SoC rev A:  sam_e70_xplained

Version SoC rev B:  sam_e70b_xplained

 

> Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

> “Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

> Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

The range [1,3] is for SoC rev A.

 

Make sure you always use version B since your SoC is the last version and you will see range [1,6].

 

BR,

Gerson

 

Em qua., 8 de jul. de 2020 às 23:11, Sam Wong <sam@...> escreveu:

Tried many times. No change, still don’t have sam_e70b_xplained.

I even tried from scratch, ran

 

                West init ~/zephyr

                Cd ~/zephyr

                West update

                Cd zephyr

                West build -p auto -b sam_e70_xplained samples/net/telnet

 

Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

“Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

 

Thanks.

Sam

 

 

 

 

From: Stephanos Ioannidis <root@...>
Date: Wednesday, July 8, 2020 at 5:15 PM
To: Sam Wong <sam@...>, Gerson Fernando Budke <nandojve@...>
Cc: "users@..." <users@...>
Subject: RE: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Have you tried ‘west update’?

 

Stephanos

 

From: users@... <users@...> On Behalf Of Sam Wong via lists.zephyrproject.org
Sent: Thursday, July 9, 2020 7:47 AM
To: Gerson Fernando Budke <nandojve@...>
Cc: users@...
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: Reading data from LSM6DS33 , I2C

Lawrence King
 

Did you power up the Accelerometer? You should read the full datasheet, here is what is says about power:

 

Operating modes

The LSM6DS33 has three operating modes available:

only accelerometer active and gyroscope in power-down

only gyroscope active and accelerometer in power-down

both accelerometer and gyroscope sensors active with independent ODR

The accelerometer is activated from power down by writing ODR_XL[3:0] in CTRL1_XL

(10h) while the gyroscope is activated from power-down by writing ODR_G[3:0] in

CTRL2_G (11h). For combo mode the ODRs are totally independent.

 

There are a lot of registers (about 60) in this chip, you need to setup the chip before you can use it. Did you set the output data rates? The Fifo? The filters?

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Edyta Bosacka
Sent: Friday, July 24, 2020 5:27 AM
To: users@...
Subject: [Zephyr-users] Reading data from LSM6DS33 , I2C

 

Hi 🙂

I want to read some data (axis_X) from accelerometer but I constantly get "0" answer. 

 


I think my code is fine, but I dont know what could be a reason of my problem
🙁

 


Reading data from LSM6DS33 , I2C

Edyta Bosacka <edyta.bosacka@...>
 

Hi 🙂
I want to read some data (axis_X) from accelerometer but I constantly get "0" answer. 



I think my code is fine, but I dont know what could be a reason of my problem 🙁




Re: Reading data from LSM6DS33 , I2C

Adam Podogrocki
 

Edyta,

WHO_AM_I_REG should be the third parameter, not forth.

Cheers,
Adam


On Thu, 23 Jul 2020 at 16:47, Lawrence King <lawrence.king@...> wrote:

Hi Edyta

 

Your code doesn’t show what value you used for I2C_ADDR. You will not get an ACK on the I2C bus if you have the wrong I2C addr for the LSM3DS33. Without an ACK, you get a bus error.

 

I think your I2C_ADDR should be 0x6B.

 

The WHO_AM_I register in the  LSM3DS33 is 0x0F, not 0xF0.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Edyta Bosacka
Sent: Thursday, July 23, 2020 9:35 AM
To: users@...
Subject: [Zephyr-users] Reading data from LSM6DS33 , I2C

 

I am trying to get Who I am data from accelerometer LSM6DS33, but I cannot receive them.  I' m getting this error: I2C transfer errorI am: 0. What can be the reason of this? 

 

#define LSM6DS33_XG_WHO_AM_I_ADDR                            0xF0

 

static int i2c_read_byte(struct device *i2c_dev_0uint8_t *datauint32_t num_bytesuint16_t addr ){

 

    uint8_t wr_addr;

    struct i2c_msg msgs[2];

    

    /*Register addres*/

    wr_addr = addr;

 

    /*Setup I2C messages*/

 

    /*Send the address to read*/

    msgs[0].buf = &wr_addr;

    msgs[0].len = 1U;

    msgs[0].flags = I2C_MSG_WRITE;

 

    /*read from device*/

    msgs[1].buf = data;

    msgs[1].len = num_bytes;

    msgs[1].flags = I2C_MSG_READ | I2C_MSG_STOP;

 

    return i2c_transfer(i2c_dev_0, &msgs[0],2I2C_ADDR);

 

}

 

 

//Read Who i am

    data[0] = 0x00;

    int err = i2c_read_byte(i2c_dev_0, &data[0], 1LSM6DS33_XG_WHO_AM_I_ADDR);

    if(err){

        printk("I2C transfer error");

    }

    printk("I am: %s \n"data[0]);

 


Re: Reading data from LSM6DS33 , I2C

Lawrence King
 

Hi Edyta

 

Your code doesn’t show what value you used for I2C_ADDR. You will not get an ACK on the I2C bus if you have the wrong I2C addr for the LSM3DS33. Without an ACK, you get a bus error.

 

I think your I2C_ADDR should be 0x6B.

 

The WHO_AM_I register in the  LSM3DS33 is 0x0F, not 0xF0.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Edyta Bosacka
Sent: Thursday, July 23, 2020 9:35 AM
To: users@...
Subject: [Zephyr-users] Reading data from LSM6DS33 , I2C

 

I am trying to get Who I am data from accelerometer LSM6DS33, but I cannot receive them.  I' m getting this error: I2C transfer errorI am: 0. What can be the reason of this? 

 

#define LSM6DS33_XG_WHO_AM_I_ADDR                            0xF0

 

static int i2c_read_byte(struct device *i2c_dev_0uint8_t *datauint32_t num_bytesuint16_t addr ){

 

    uint8_t wr_addr;

    struct i2c_msg msgs[2];

    

    /*Register addres*/

    wr_addr = addr;

 

    /*Setup I2C messages*/

 

    /*Send the address to read*/

    msgs[0].buf = &wr_addr;

    msgs[0].len = 1U;

    msgs[0].flags = I2C_MSG_WRITE;

 

    /*read from device*/

    msgs[1].buf = data;

    msgs[1].len = num_bytes;

    msgs[1].flags = I2C_MSG_READ | I2C_MSG_STOP;

 

    return i2c_transfer(i2c_dev_0, &msgs[0],2I2C_ADDR);

 

}

 

 

//Read Who i am

    data[0] = 0x00;

    int err = i2c_read_byte(i2c_dev_0, &data[0], 1LSM6DS33_XG_WHO_AM_I_ADDR);

    if(err){

        printk("I2C transfer error");

    }

    printk("I am: %s \n"data[0]);

 


Reading data from LSM6DS33 , I2C

Edyta Bosacka <edyta.bosacka@...>
 

I am trying to get Who I am data from accelerometer LSM6DS33, but I cannot receive them.  I' m getting this error: I2C transfer errorI am: 0. What can be the reason of this? 

#define LSM6DS33_XG_WHO_AM_I_ADDR                            0xF0

static int i2c_read_byte(struct device *i2c_dev_0uint8_t *datauint32_t num_bytesuint16_t addr ){

    uint8_t wr_addr;
    struct i2c_msg msgs[2];
    
    /*Register addres*/
    wr_addr = addr;

    /*Setup I2C messages*/

    /*Send the address to read*/
    msgs[0].buf = &wr_addr;
    msgs[0].len = 1U;
    msgs[0].flags = I2C_MSG_WRITE;

    /*read from device*/
    msgs[1].buf = data;
    msgs[1].len = num_bytes;
    msgs[1].flags = I2C_MSG_READ | I2C_MSG_STOP;

    return i2c_transfer(i2c_dev_0, &msgs[0],2I2C_ADDR);

}


//Read Who i am
    data[0] = 0x00;
    int err = i2c_read_byte(i2c_dev_0, &data[0], 1LSM6DS33_XG_WHO_AM_I_ADDR);
    if(err){
        printk("I2C transfer error");
    }
    printk("I am: %s \n"data[0]);


embed data files

adpauly@...
 

Dear Experts,

I am new to zephyr and working with nRF9160dk related development.

For testing some functionalities, I thought to include some 'raw resource binary data file' in the code as in the linux's "/etc/<some_config_file>". I am using segger studio. Is it possible to embed some data files in the code and to build an application ? I did a search in the samples, but did not find anything similar. 

Thanks,


Re: Zephyr - read I2C sample, nrf52840

Lawrence King
 

Hi Edyta:

 

There are two ways to read sensors. If your sensor has a driver and you have set it up in the device tree correctly you can simply use the sensor examples.

 

If your sensor is really simple, you can cheat and just send i2c packets directly to the sensor from a user program. Here is an example of driving a really simple I/O expander:

 

/* Zephyr specific includes */

#include <zephyr.h>

#include <zephyr/types.h>

#include <device.h>

#include <drivers/i2c.h>

 

#define PCA9536_RED_LED_PIN             0

#define PCA9536_GREEN_LED_PIN           1

#define PCA9536_BLUE_LED_PIN            2

#define PCA9536_I2C_ADDR                (0x82 >> 1)

uint8_t pca9536_state;

 

/* The PCA9536 chip has four 8-bit registers

*      0 - input port register - read only

*      1 - output port register - read/write

*      2 - polarity inversion register - read/write

*              0=normal, 1=invert (only affects the input register)

*      3 - configuration register - read/write

*              0=output, 1=input

* each register has 4-bits corresponding to the 4 GPIOs on the chip

*

* writing a register is reasonably easy (one 3-byte transaction)

*      1) send the device address and the register read/write bit set to 0 (write)

*      2) send the command byte, the command byte contains the address of the register above that you want to write

*      3) write the the contents of the register. the upper 4 bits should always be 1.

*

* reading a register is a multi step process (two 2-byte transactions)

*      1) send the device address and the register read/write bit set to 0 (write)

*      2) send the command byte, the command byte contains the address of the register above that you want to read

*      this completes the first transaction

*      3) send the device address and the register read/write bit set to 1 (read)

*      4) read the response byte, which is the contents of the register. the upper 4 bits should always be 1.

*/

void    pca9536_init(void)

{

        int i;

        struct  i2c_msg msgs[2];

        u8_t data[2][2];

 

        /* printf("pca9536_init().\n"); */

        i2c_dev = device_get_binding("I2C_1");

        if (!i2c_dev) {

                printf("pca9536_init(): I2C Device driver not found.\n");

                return;

        }

        /* set the pins to outputs, and drive high */

        data[0][0] = 3;    /* config register */

        data[0][1] = 0xFF ^ ((1 << PCA9536_RED_LED_PIN) | (1 << PCA9536_GREEN_LED_PIN) | (1 << PCA9536_BLUE_LED_PIN));  /* 3 outputs */

        msgs[0].buf = data[0];

        msgs[0].len = 2U;

        msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

 

        data[1][0] = 1;              /* output register */

        data[1][1] = ((1 << PCA9536_RED_LED_PIN) | (1 << PCA9536_GREEN_LED_PIN) | (1 << PCA9536_BLUE_LED_PIN)); /* 3 highs */

        msgs[1].buf = data[1];

        msgs[1].len = 2U;

        msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

        i = i2c_transfer(i2c_dev, &msgs[0], 2, (u8_t)PCA9536_I2C_ADDR);

        if (i != 0) {

                printf("pca9536_init(): transfer failed.\n");

                return;

        }

}

 

void    pca9536_set(void)

{

        int i;

        struct  i2c_msg msgs[2];

        u8_t data[2][2];

 

        data[0][0] = 1; /* output register */

        data[0][1] = pca9536_state;

        msgs[0].buf = data[0];

        msgs[0].len = 2U;

        msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

        i = i2c_transfer(i2c_dev, &msgs[0], 1, (u8_t)PCA9536_I2C_ADDR);

        if (i != 0) {

                printf("pca9536_set(): transfer failed.\n");

                return;

        }

}

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Edyta Bosacka
Sent: Wednesday, July 22, 2020 8:44 AM
To: users@...
Subject: [Zephyr-users] Zephyr - read I2C sample, nrf52840

 

Is there any example how to read data from sensor by I2C?


Zephyr - read I2C sample, nrf52840

Edyta Bosacka <edyta.bosacka@...>
 

Is there any example how to read data from sensor by I2C?


Re: [Zephyr-devel] Community input on possible change to Discord from Slack

Jett ✈ Rink <jettrink@...>
 

If Zephyr is non-profit (which it seems to be), then it will be eligible to sign up for G Suite for nonprofit which includes many features for free. I have personally set this up for two non-profits and it is pretty straightforward.

I agree that chat.google.com is very well hidden ;)

-Jett

On Tue, Jul 21, 2020 at 6:15 PM Nashif, Anas <anas.nashif@...> wrote:

Jett,

Zephyr project is not subscribed to any gsuite plans, free or paid. AFAIK we use google docs from LF in some areas. Maybe we should look into the non-profit “companies” option.

Never heard of chat.google.com, well hidden 😊

 

Anas

 

From: <devel@...> on behalf of "Jett Rink via lists.zephyrproject.org" <jettrink=google.com@...>
Reply to: "jettrink@..." <jettrink@...>
Date: Tuesday, 21 July 2020 at 19:17
To: Henrik Brix Andersen <henrik@...>
Cc: Kumar Gala <kumar.gala@...>, zephyr-devel <zephyr-devel@...>, Ryan Johnson via Zephyr-users <zephyr-users@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

 

-Jett

 

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>




Re: [Zephyr-devel] Community input on possible change to Discord from Slack

Nashif, Anas
 

Jett,

Zephyr project is not subscribed to any gsuite plans, free or paid. AFAIK we use google docs from LF in some areas. Maybe we should look into the non-profit “companies” option.

Never heard of chat.google.com, well hidden 😊

 

Anas

 

From: <devel@...> on behalf of "Jett Rink via lists.zephyrproject.org" <jettrink=google.com@...>
Reply to: "jettrink@..." <jettrink@...>
Date: Tuesday, 21 July 2020 at 19:17
To: Henrik Brix Andersen <henrik@...>
Cc: Kumar Gala <kumar.gala@...>, zephyr-devel <zephyr-devel@...>, Ryan Johnson via Zephyr-users <zephyr-users@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

 

-Jett

 

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>




Re: [Zephyr-devel] Community input on possible change to Discord from Slack

Jett ✈ Rink <jettrink@...>
 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

-Jett

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:
Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>





API meeting: agenda

Carles Cufi
 


Re: [Zephyr-devel] Community input on possible change to Discord from Slack

Henrik Brix Andersen
 

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen

On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:

All,

We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage. The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.

We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option. A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).

Some requirements for Zephyr chat platform:
* Maintain history
* integration with other services (like GitHub)
* private channels
* ideally free - or low cost
* no overhead for Zephyr Project (ie not having to run our own server).

Pros of Discord:
* Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
* Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
* Unlimited history for free.
* Easy to join via invite link, chat and then establish an account.

Cons of Discord:
* Can get spammy when publicly listed.
* Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
* Closed source so interop with Matrix and IRC is tricky but doable.

We’d like to get any feedback from the community at large before finalizing a decision in the TSC. The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.

Thanks

A few links:
* Current Open Source communities utilizing Discord: https://discord.com/open-source
* Zephyr Discord: https://discord.gg/28BgkM

(NOTE: The Zephyr Discord is setup for testing purposes at this time)


Testing DTLS with the echo_client and echo_server samples #ble #crypto #nrf52832

Stefan Hristozov
 

Hi all,

I want to test DTLS in IPv6 over BLE network.
My set up looks as follows:
                  BLE                                                                     wifi                        wifi
nrf52832 --------------------- Raspberry Pi Border router --------------- WIFI router --------------- PC
2001:db8::1                       2001:db8::2     2001:db9::1                                                  2001:db9::2

1) I compiled the echo_server with:

west build -- -DOVERLAY_CONFIG=overlay-bt.conf

and flashed it on an nrf52832 DK board. The board connects aimlessly with the border router.


2) In another terminal I compiled the echo_client for netive_posix:

west build -b native_posix,

I started the zephyrproject/tools/net-tools/net-setup.sh, and then the native_posix application with:

west build -t run.

3) In another terminal, I started tcpdump listening to the zeht interface. Unfortunately, I cannot see any packets send or received. The console output of the echo_client and echo_servers also does not indicate the something was send or received.

I want to test the sending and receiving of DTLS packets at the nrf52832 board in the three modes:
* Preshared Keys PSK
* Raw Public Keys RPK
* Certificates
I want to secure only UDP over IPv6 (No TCP and no IPv4).

My Questions are:
1) Is the described above procedure correct? I assume something is wrong otherwise I will see some exchanged packets with tcpdump and console output?
2) How to select the DTLS modes PSK/RPK/Certificates?
3) The echo_client and echo_server samples are very complex. Can you point me to a more simple example or describe the procedure for setting up a secured with DTLS UDP communication?

Best regards,
Stefan


Re: MCUMGR - sends responses to wrong port

Lawrence King
 

Thanks Charles.

 

Bug #26939 filed…. Let me know if there is any other info I can provide.

 

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

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Friday, July 17, 2020 4:49 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Right, I think I understand what you mean. This is almost certainly a bug in the SMP shell transport, but just to make sure, please:

 

  • Create an issue on GitHub with this description
  • Include the prj.conf and .config files, so we can see if you are using CONFIG_MCUMGR_SMP_SHELL or CONFIG_MCUMGR_SMP_UART as a transport
  • Include the .dts file as well so we can make sure we see the aliases defined

 

Thanks,

 

Carles

 

 

From: Lawrence King <lawrence.king@...>
Sent: 17 July 2020 01:52
To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Charles,

 

I tried your suggestion, unfortunately it doesn’t help. Every dts that uses mcumgr, also has the console on the same port, there is no existing board that routes the mcumgr to a different place than the console. Hence you would never have seen this issue.

 

The function smp_shell_tx_raw() in subsys/mgmt/smp_shell.c is hard coded to always send the response via k_str_out(). k_str_out() is part of  lib/os/printk and calls __char_out(). The function __char_out() is hooked into printk with the function __printk_hook_install() very early in the kernel boot phases and all the places that the hook is installed always installs it to the console.

 

The shell can be run on any port, not just the console, and we can add mcumgr to the shell. When the shell is running on a different port it is correctly passing the received data to smp_shell, its just that smp_shell sends the reply out to the console, and not to the port the shell is running on.

 

When smp_uart.c is ready to transmit a packet it calls mcumgr_serial_tx_pkt(), which then breaks the packet into frames and calls mcumgr_serial_tx_frame(). In turn mcumgr_serial_tx_frame() breaks the frame into bytes and calls mcumgr_serial_tx_small(). mcumgr_serial_tx_small() then base64 encodes the bytes and calls the mcumgr_serial_tx_cb to send 4 chars. Up to this point is all looking like it should. A pointer (cb) to the tx callback was passed all along this chain, so it should be possible to route the reply packet to the correct port.

 

Unfortunately when smp_shell_tx_pkt() called mcumgr_serial_tx_pkt() it passed a pointer to the function smp_shell_tx_raw() as the transmit callback. smp_shell_tx_raw is hard coded to send to the console, not the port the shell is running on. When smp_shell_init() was called it was passed a device pointer which is the device that the packets are coming in on, and going out on. But smp_shell_init() threw away this information when it called zephyr_smp_transport_init(). Uart_mcumgr does a little better than smp_shell, it also throws away the device information, but instead of being hard coded to the console, it outputs data to CONFIG_UART_MCUMGR_ON_DEV_NAME.

 

 

 

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Thursday, July 16, 2020 5:15 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

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: MCUMGR - sends responses to wrong port

Carles Cufi
 

Hi Lawrence,

 

Right, I think I understand what you mean. This is almost certainly a bug in the SMP shell transport, but just to make sure, please:

 

  • Create an issue on GitHub with this description
  • Include the prj.conf and .config files, so we can see if you are using CONFIG_MCUMGR_SMP_SHELL or CONFIG_MCUMGR_SMP_UART as a transport
  • Include the .dts file as well so we can make sure we see the aliases defined

 

Thanks,

 

Carles

 

 

From: Lawrence King <lawrence.king@...>
Sent: 17 July 2020 01:52
To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Charles,

 

I tried your suggestion, unfortunately it doesn’t help. Every dts that uses mcumgr, also has the console on the same port, there is no existing board that routes the mcumgr to a different place than the console. Hence you would never have seen this issue.

 

The function smp_shell_tx_raw() in subsys/mgmt/smp_shell.c is hard coded to always send the response via k_str_out(). k_str_out() is part of  lib/os/printk and calls __char_out(). The function __char_out() is hooked into printk with the function __printk_hook_install() very early in the kernel boot phases and all the places that the hook is installed always installs it to the console.

 

The shell can be run on any port, not just the console, and we can add mcumgr to the shell. When the shell is running on a different port it is correctly passing the received data to smp_shell, its just that smp_shell sends the reply out to the console, and not to the port the shell is running on.

 

When smp_uart.c is ready to transmit a packet it calls mcumgr_serial_tx_pkt(), which then breaks the packet into frames and calls mcumgr_serial_tx_frame(). In turn mcumgr_serial_tx_frame() breaks the frame into bytes and calls mcumgr_serial_tx_small(). mcumgr_serial_tx_small() then base64 encodes the bytes and calls the mcumgr_serial_tx_cb to send 4 chars. Up to this point is all looking like it should. A pointer (cb) to the tx callback was passed all along this chain, so it should be possible to route the reply packet to the correct port.

 

Unfortunately when smp_shell_tx_pkt() called mcumgr_serial_tx_pkt() it passed a pointer to the function smp_shell_tx_raw() as the transmit callback. smp_shell_tx_raw is hard coded to send to the console, not the port the shell is running on. When smp_shell_init() was called it was passed a device pointer which is the device that the packets are coming in on, and going out on. But smp_shell_init() threw away this information when it called zephyr_smp_transport_init(). Uart_mcumgr does a little better than smp_shell, it also throws away the device information, but instead of being hard coded to the console, it outputs data to CONFIG_UART_MCUMGR_ON_DEV_NAME.

 

 

 

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Thursday, July 16, 2020 5:15 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

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: Community input on possible change to Discord from Slack

Armand C.
 

Hi,

Being a user of a self-hosted instance of Mattermost (https://mattermost.com/) for some time, the experience is quite positive. We have a basic usage though and I'm not sure it fulfills all requirements. Maybe worth having a look anyway.

Armand

On 17.07.20 00:27, Kumar Gala wrote:
All,
We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage. The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option. A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
Some requirements for Zephyr chat platform:
* Maintain history
* integration with other services (like GitHub)
* private channels
* ideally free - or low cost
* no overhead for Zephyr Project (ie not having to run our own server).
Pros of Discord:
* Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
* Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
* Unlimited history for free.
* Easy to join via invite link, chat and then establish an account.
Cons of Discord:
* Can get spammy when publicly listed.
* Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
* Closed source so interop with Matrix and IRC is tricky but doable.
We’d like to get any feedback from the community at large before finalizing a decision in the TSC. The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
Thanks
A few links:
* Current Open Source communities utilizing Discord: https://discord.com/open-source
* Zephyr Discord: https://discord.gg/28BgkM
(NOTE: The Zephyr Discord is setup for testing purposes at this time)


Re: Community input on possible change to Discord from Slack

rs@...
 

Hi Kumar,

Being a Matrix homeserver administrator myself (Synapse/Riot-Web), but
never having used Discord, I'd like to know what (apart form Adafruit)
made Discord look like the most interesting candidate?

On 7/17/20 12:27 AM, Kumar Gala wrote:
Some requirements for Zephyr chat platform:
* Maintain history
Can not see a problem with this.

* integration with other services (like GitHub)
Never done this, can not say anything about it.

* private channels
Possible - including E2E encryption

* ideally free - or low cost
* no overhead for Zephyr Project (ie not having to run our own server).
What would be considered low cost?

Would a server maintained paid by the LF and run by a volunteer be an
option?

Pros of Discord:
* Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
Same for Matrix, but solved via federation

* Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
I had no need yet on my homeserver (~150 accounts), but mute/kick/ban is
not a problem at all. Also, redacting history of a spammer, etc. is very
possible.

* Unlimited history for free.
Possible

* Easy to join via invite link, chat and then establish an account.
I have not tried to enable guest accounts yet, but ...
a) it is very easy to set up a homeserver to allow registering with just
a username and a password, not requiring an e-mail or phone number.
b) People can just re-use their existing Matrix accounts if federation
is enabled

Cons of Discord:
* Can get spammy when publicly listed.
For matrix, sharing the room list with other homeservers can be prevented.

* Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
* Closed source so interop with Matrix and IRC is tricky but doable.
Matrix.org does already IRC bridging for its own *and* users on other
homeservers [1].

Also, the speed at which Synapse/Element/etc. is getting developed is
awesome. There are releases pretty much every week, each containing
serious improvements.

Greetings,
Reto

[1]
https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges-all-of-freenode