Date   
FW: Zephyr CMake package / find_package(Zephyr)

Carles Cufi
 

 

 

From: announce@... <announce@...> On Behalf Of Rasmussen, Torsten via Lists.Zephyrproject.Org
Sent: 30 March 2020 15:32
To: announce@...
Cc: announce@...
Subject: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

 

Hi All,

 

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

 

This means a simple Zephyr application now looks as:

# Find Zephyr. This also loads Zephyr's build system.

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

project(my_zephyr_app)

 

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

 

For this to work, it is necessary to execute a new west command: `west zephyr-export`

This command only needs to be executed once, for example after a `west init`

 

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

 

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

 

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,

but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

 

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

 

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

 

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):

https://docs.zephyrproject.org/latest/getting_started/index.html

https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html

 

 

Best regards

 

Torsten

 

Re: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

Kumar Gala
 

What version of west has 'zephyr-export’??

[galak@spiff zephyr]$ west -V
West version: v0.7.2
[galak@spiff zephyr]$ west zephyr-export
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'zephyr-export' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate', 'completion', 'boards', 'build', 'sign', 'flash', 'debug', 'debugserver', 'attach’)- k

- k

On Mar 30, 2020, at 8:31 AM, Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:

Hi All,

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

This means a simple Zephyr application now looks as:
# Find Zephyr. This also loads Zephyr's build system.
cmake_minimum_required(VERSION 3.13.1)
find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})
project(my_zephyr_app)

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

For this to work, it is necessary to execute a new west command: `west zephyr-export`
This command only needs to be executed once, for example after a `west init`

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,
but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):
https://docs.zephyrproject.org/latest/getting_started/index.html
https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html


Best regards

Torsten

Re: Development Issue on LPC55S69

Lawrence King
 

Hi Vince:

 

2) I am not sure what you mean when you say “the voltage on the MOSI signal is unstable”. The Oscilloscope traces below look fine, however, the probes on your oscilloscope have not been properly compensated hence you see the ‘tilt’ on the signals instead of nice square waves. Take a look at this article to understand why and how to compensate your probes. https://www.circuitspecialists.com/blog/oscilloscope-probe-compensation-adjustment/

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Vince Wu (???)
Sent: Monday, March 30, 2020 12:46 AM
To: devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: [Zephyr-devel] Development Issue on LPC55S69

 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

  1. EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

  1. The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

  1. Start from high voltage and end with high voltage
  2. Start from high voltage and end with low voltage
  3. Start from low voltage and end with high voltage
  4. Start from low voltage and end with high voltage

For example:

 

  1. No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

  1. Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 

Development Issue on LPC55S69

Vince Wu (吳家瑋) <Vince.Wu@...>
 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

1.      EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

2.      The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

1.      Start from high voltage and end with high voltage

2.      Start from high voltage and end with low voltage

3.      Start from low voltage and end with high voltage

4.      Start from low voltage and end with high voltage

For example:

 

3.      No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

4.      Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 

Zephyr CMake package / find_package(Zephyr)

Rasmussen, Torsten
 

Hi All,

 

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

 

This means a simple Zephyr application now looks as:

# Find Zephyr. This also loads Zephyr's build system.

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

project(my_zephyr_app)

 

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

 

For this to work, it is necessary to execute a new west command: `west zephyr-export`

This command only needs to be executed once, for example after a `west init`

 

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

 

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

 

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,

but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

 

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

 

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

 

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/getting_started/index.rst

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/guides/zephyr_cmake_package.rst

 

(Still waiting for the docs to be rebuilt)

 

 

Best regards

 

Torsten

 

 

Re: Most BLE applications with nrf52 boards are broken on Version 2.1

Bolivar, Marti
 

The beacon sample builds for me at Zephyr v2.1.0 for nrf52_pc10040 with
Zephyr SDK 0.11.1.

Did you skip a 'west update' or need a --prisitine?

"Li, Jun R via Lists.Zephyrproject.Org"
<jun.r.li=intel.com@...> writes:

Hey,
I’ve tried to build a couple of BLE applications, like “beacon” , “peripheral_hr” with several nRF52 boards such as “nrf52_pca10040”, “nrf52840_pca10056” on the version 2.1. All building process is broken at the link stage with the following errors:

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `le_set_private_addr':
/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:581: undefined reference to `bt_rand'
/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `create_random_addr':
/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:4658: undefined reference to `bt_rand'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:579: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

I’m not sure if the CI process still covers the tests for most applications.

Regards,
Jun

--


Most BLE applications with nrf52 boards are broken on Version 2.1

Li, Jun R
 

Hey,

I’ve tried to build a couple of BLE applications, like “beacon” , “peripheral_hr” with several nRF52 boards such as “nrf52_pca10040”, “nrf52840_pca10056” on the version 2.1. All building process is broken at the link stage with the following errors:

 

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `le_set_private_addr':

/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:581: undefined reference to `bt_rand'

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `create_random_addr':

/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:4658: undefined reference to `bt_rand'

collect2: error: ld returned 1 exit status

zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed

make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1

CMakeFiles/Makefile2:579: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed

make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2

Makefile:83: recipe for target 'all' failed

make: *** [all] Error 2

 

I’m not sure if the CI process still covers the tests for most applications.

 

Regards,

Jun

 

-- 

 

ZEBRA RFC source tree location #ble

deang@...
 

The ZEBRA RFC (see RFC: https://github.com/zephyrproject-rtos/zephyr/issues/23465) is a feature proposal for a simple way to add secure authentication between two Bluetooth devices.  ZEBRA is not part of the Bluetooth stack, it uses the Bluetooth stack via the firmware application to authenticate.   There are several places where the ZEBRA code could potentially resided within the Zephyr code base:


  1. As a sub directory of subsys.   subsys/auth
Good option.  The subsys directory contains key components of Zephyr.  While you can use Zephyr without a sub system, say networking, these components are often critical and used in an embedded system.  The subsys/auth subdirectory would contain ZEBRA and other authentication methods such as Google Fast Pair.   As security becomes more important to real time systems, it makes sense to make authentication a key component of Zephyr.  A subsys/auth would also enable code sharing between different authentication methods.


2.  As a sub directory lib.   lib/auth
Good option.  The lib directory contains various libraries, ZEBRA can is essentially a library sitting on top of the Bluetooth stack providing authentication services.  Other authentication methods would be separate libraries. 


Looking for suggestions and comments on which option would work the best. 

I personally prefer option #1.  

Thanks,

Dean Gereaux

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 03/26/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 26 March 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Dev-Review Meeting Agenda Mar 25

Kumar Gala
 

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review
* use of PRE_KERNEL_1/PRE_KERNEL_2...
* Pinmux/pinctrl (Piotr/Erwan)
* Any topics anyone else has

- k

Zephyr crypto APIs and mbed TLS

Carles Cufi
 

Hi all,

I was wondering about the state of crypto APIs in Zephyr and whether it makes sense to move them forward or instead we should consider simply using the mbed TLS set of APIs as Zephyr's crypto API.

The reason I say this is that today we have include/crypto/cipher.h which abstracts ciphers, but that's about it. Most users in the code seem to use mbed TLS APIs directly when they require crypto functionality (with the exception of Bluetooth which can use TinyCrypt or mbed TLS and has its own abstraction) with only the IEEE 802.15.4 stack using cipher.h.
mbed TLS is a recognized crypto API that (as far as I know) can be used with or without the actual mbed TLS implementation, so I question the need to define our own in this particular case, although I might be missing key information. Unless I am mistaken one can implement hardware-accelerated or custom or proprietary implementations of crypto functions and shim them so that they expose the mbed TLS API.

In any case I do believe this is something that needs discussion since the current usage in the tree is inconsistent and the subset of APIs defined in include/crypto is very small.

If we did decide to use mbed TLS as an API we would then also need to discuss how to go about it, since mbed TLS is today an (optional) module and therefore the header files themselves are not included in the main zephyr tree.

Input welcome!

Regards,

Carles

Re: nrf52840 ble error #ble #nrf52840

Narendar Malepu
 

Yes previously I posted same issue, but iam not creating any threads in my application


On Tue, 24 Mar, 2020, 2:14 PM Chettimada, Vinayak Kariappa, <vinayak.kariappa.chettimada@...> wrote:

Please create a github issue with details of building your application and steps to reproduce the issue.

Do specify the commit hash, and if you have a branch, do mention that too.

 

I see you have re-sent this mail again to mailing list, did you try measuring the stack usage of threads using the PR mentioned in previous email threads?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 24 March 2020 07:20
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)

[00:01:36.902,893] <err> os: ***** BUS FAULT *****

[00:01:36.902,893] <err> os:   Imprecise data bus error

[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000

[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb

[00:01:36.902,923] <err> os:  xpsr:  0x61000000

[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee

[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)

[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

Upcoming Event: Zephyr Project: APIs - Tue, 03/24/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 24 March 2020, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

Re: net_buf: non-atomic reference counting

Paul Sokolovsky
 

Hello,

On Tue, 24 Mar 2020 11:25:48 +0200
"Jukka Rissanen" <jukka.rissanen@...> wrote:

Hi Darryl,

I think it is more of a historical relic than a purpose design. There
has not been any reports that this have caused issues. Patches are
welcome of course.
Perhaps it could be rephrased differently: net_buf is more like Zephyr's
internal system object. Where it's used currently, thread
synchronization is expected(*) to happen on different level(s), and
net_buf itself is kept lightweight and optimized. Perhaps that can be
changed, but effects on existing subsystems using net_buf should be
considered.

(*) That doesn't mean there're no bugs, so reproducible bugreports are
welcome.


Cheers,
Jukka


On Sun, 2020-03-22 at 17:39 -0700, Darryl Gamroth wrote:
Hi all,

I was looking at using net_bufs for an application broadcasting
reference counted buffers to multiple threads and I noticed the
reference counting is not atomic. I'm curious, is this by design?

Thanks.

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

API meeting: agenda

Carles Cufi
 

Hi all,

Note: This is the last week where the meeting takes place at 17h CET. Next week we go back to 18h CET.

Today's topics:

- How to document standalone drivers like the enc28j60 (Piotr)

- Upgrade the hwinfo API to stable
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23661

- RTC API proposal
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/commits/2880ee02b0f2fd91d897d8a11a4cbdefe87a19b0

- Naming in the async_notify module
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23601

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

Re: net_buf: non-atomic reference counting

Jukka Rissanen
 

Hi Darryl,

I think it is more of a historical relic than a purpose design. There
has not been any reports that this have caused issues. Patches are
welcome of course.

Cheers,
Jukka

On Sun, 2020-03-22 at 17:39 -0700, Darryl Gamroth wrote:
Hi all,

I was looking at using net_bufs for an application broadcasting
reference counted buffers to multiple threads and I noticed the
reference counting is not atomic. I'm curious, is this by design?

Thanks.

Re: nrf52840 ble error #ble #nrf52840

Chettimada, Vinayak Kariappa
 

Please create a github issue with details of building your application and steps to reproduce the issue.

Do specify the commit hash, and if you have a branch, do mention that too.

 

I see you have re-sent this mail again to mailing list, did you try measuring the stack usage of threads using the PR mentioned in previous email threads?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 24 March 2020 07:20
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)

[00:01:36.902,893] <err> os: ***** BUS FAULT *****

[00:01:36.902,893] <err> os:   Imprecise data bus error

[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000

[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb

[00:01:36.902,923] <err> os:  xpsr:  0x61000000

[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee

[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)

[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

nrf52840 ble error #ble #nrf52840

Narendar Malepu
 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)
[00:01:36.902,893] <err> os: ***** BUS FAULT *****
[00:01:36.902,893] <err> os:   Imprecise data bus error
[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000
[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb
[00:01:36.902,923] <err> os:  xpsr:  0x61000000
[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee
[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)
[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

net_buf: non-atomic reference counting

Darryl Gamroth
 

Hi all,

I was looking at using net_bufs for an application broadcasting reference counted buffers to multiple threads and I noticed the reference counting is not atomic. I'm curious, is this by design?

Thanks.

[API stability change] Request to change the stability of HWINFO from unstable to stable

Alexander Wachter <alexander@...>
 

Dear all,

This email is a request to change the stability of the Hardware Information API from "unstable" to "stable".

Pull-request: #23661
Discussion in the API meeting takes place on Tuesday, March 24th.

If there are any objections, please comment on the PR or attend to the API meeting.

Kind regards,

--
Alexander Wachter

The guy who introduced this API