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/

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

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.

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

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

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

Hi,

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

Notes/Minutes

Status updates

• Status update from Wayne regarding PR#22668
• No news.
• Status update from Thomas regarding IAR: Nothing new. regarding PR#22668
• Has been working on two routes: 
• CMake

• work has come fairly far.
• not able to build entire chain, but fairly close,

expect to hit same include files issue, as with using IAR IDE.

• IAR IDE

• Struggle with include file issue, as there are much gcc specific include (gcc assembly)

This will be hard to solve.

• IAR Linking

• IAR has --whole-archive support, so should not be an issue.
• Thomas has looked into linker script generation in other projects
• TF-M generates toolchain specific linker script.
  Those are based on toolchain specific templates.
• Mbed specific linker script for each toolchain.
• cmsis uses memory layer on target

There are attributes set per target regarding memory:

read-only

read-write

Settings are specified in an xml file

AP:

•  Nothing new

Short term goals:

• Toolchain test cases
• Test cases should not be ordinary Zephyr tests

Could be completely different test system with focus on:

• Optimization
• Linker
• archive
• Should test features that is known to be used inside Zephyr
• Determine what is most important to test / ensure support for.
• Needs to work with any toolchain, also out-of-tree toolchains.

Toolchain abstraction:

• Several choices in current Zephyr originates from the early KBuild solution, as example, the cross-compiler interface.
• Consider to drop compatibility to old legacy, in order to ease the process of going forward.
• Things was carried over from KBuild, without cleaning up
• Consider drop support for not-used features
• Support for toolchain files

• Current situation is that in order to add additional toolchain support, then there is a need to implement a lot of macros, even macros that is of no interest, and thus just empty.
• To improve:
  The toolchain abstraction interface must be improved. (Agreed by everyone)

• Note: It is still important to ensure the possibility of out-of-tree toolchains.
  Also, keep in mind there are users that are using the current toolchain abstraction interface.

Linker

• What Zephyr faces, is a common issue
• What have other done
• What Zephyr solves might be useful for others (generic solution)
• Step 1) Get it working for Zephyr, but have the generic support in mind.

Best regards

Torsten T. Rasmussen