users@lists.zephyrproject.org

#ble #hci #usb #ble #hci #usb

valens.dsilva@...

#2238

Hi,

I am new to Zephyr and I'm trying to expose the LE PHY setting to a RPI Linux Host system. The controller is an nrf52840 dongle acting as a HCI USB device. The dongle will interact with the BLuez stack on the Pi (Bluez 5.55)

I have the following prj.conf setting which I took from this person https://devzone.nordicsemi.com/f/nordic-q-a/65679/zephyr-os---nrf52840-dongle-with-long-range?ReplySortBy=CreatedDate&ReplySortOrder=Descending

CONFIG_STDOUT_CONSOLE=y

CONFIG_GPIO=y

CONFIG_SERIAL=y

CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_BT=y

CONFIG_BT_H4=y

CONFIG_BT_CTLR=y

CONFIG_BT_HCI=y

CONFIG_USB=y

CONFIG_USB_DEVICE_STACK=y

CONFIG_USB_DEVICE_BLUETOOTH=y

CONFIG_USB_DEVICE_BLUETOOTH_VS_H4=y

CONFIG_MAIN_STACK_SIZE=1024

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1024

CONFIG_BT_CTLR_RX_BUFFERS=18

CONFIG_BT_CTLR_TX_BUFFERS=19

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_HCI_CMD_COUNT=20

CONFIG_BT_RX_BUF_COUNT=20

CONFIG_BT_RX_BUF_LEN=258

CONFIG_BT_DISCARDABLE_BUF_SIZE=257

CONFIG_BT_MAX_CONN=24

CONFIG_BT_CTLR_PHY_CODED=y

CONFIG_BT_PHY_UPDATE=y

CONFIG_BT_AUTO_PHY_UPDATE=y

CONFIG_BT_LLL_VENDOR_NORDIC=y

CONFIG_BT_LL_SW_SPLIT=y

When I use btmon to list the supported commands of the adapter I do not see commands such as:

LE Read Maximum Data Length (Octet 35 - Bit 3)

LE Read PHY (Octet 35 - Bit 4)

LE Set Default PHY (Octet 35 - Bit 5)

LE Set PHY (Octet 35 - Bit 6)

LE Read Transmit Power (Octet 38 - Bit 7)

LE Set Privacy Mode (Octet 39 - Bit 2)

Can someone point me to missing CONFIG values I need?
Thanks

LIS2DW12 over SPI on nRF9160 #driver #sensor #spi #lis2dw12 #nrf9160

p.swenson@...

#2237
Edited

Using: Windows 10, nRF Connect v3.5.0, SES v4.52, ncs v1.3.0, zephyr v2.3.0

I have a custom board based on the Nordic Thingy91 and the Asset Tracker application. There is also an LIS2DW12 present on SPI. In "prj.conf", I added these lines:

 
CONFIG_SENSOR=y
CONFIG_TEMP_USE_EXTERNAL=y
CONFIG_TEMP_USE_SIM=n
CONFIG_SENSOR_SIM=n
CONFIG_SPI=y
CONFIG_SPI_NRFX=y
CONFIG_SPI_3=y
CONFIG_ACCEL_USE_EXTERNAL=y
CONFIG_LIS2DW12=y
CONFIG_ACCEL_DEV_NAME="LIS2DW12"
CONFIG_LIS2DW12_ODR_1_6=y
CONFIG_LIS2DW12_ACCEL_RANGE_2G=y

I modified the Thingy91 board devicetree file "thingy91_nrf9160_common.dts":

&spi3 {
 compatible = "nordic,nrf-spim";
 status = "okay";
 sck-pin = <16>;
 mosi-pin = <13>;
 miso-pin = <14>;
 cs-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
 
 lis2dw12 {
 compatible = "stm,lis2dw12";
 label = "LIS2DW12";
 spi-max-frequency = <10000000>;
 int1-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
 };
};
 
In "lis2dw12.c", I added these lines to the top:

#define DT_DRV_COMPAT stm_lis2dw12
#define LIS2DW12 DT_INST(0, stm_lis2dw12)

In SES, it builds quite far, but I get an error:

C:/engr/ncs/v1.3.0/zephyr/drivers/sensor/lis2dw12/lis2dw12.c:227: undefined reference to `lis2dw12_spi_init'

In "lis2dw12.c", this section is grayed out:

#if DT_ANY_INST_ON_BUS_STATUS_OKAY(spi)
#include <drivers/spi.h>
#elif DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)
#include <drivers/i2c.h>
#endif
 

Which means it never includes the spi.h file. What am I missing? I can force the issue, but it just shifts the problem and doesn't solve it.

Re: FIFO is not empty after getting all data items; reference pointer still points to another item

Carles Cufi

#2236

The reason that Zephyr does not copy the items to the list is that it offers primitives that copy them (message queues) and primitives that do not (FIFOs). Then you can use FIFOs if you have your own allocation scheme that is optimized for your usecase, and message queues if you want the kernel to handle that for you.

Carles

Show quoted text

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 17 September 2020 16:57
To: Cufi, Carles <Carles.Cufi@...>; users@...
Subject: Re: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

Hi Carles,

thanks for your reply. This solved my problem.

But why does Zephyr not copy the items to the list? For me, there’s absolutely no reason to NOT copy data items to a queue . It runs the risk to…

… put data items to the queue which are on the stack of a function or an ISR. Thus, these elements would be not valid anymore when the function returns. This is a major security issue, since you won’t be able to recognize the error until it will be overwritten randomly in memory…
… put the same data item several times to the queue which has the same memory address but different content (which was actually my problem)

Furthermore I would need a separate buffer to store my queue items, if I only put pointers to the queue. So one of the main features of a queue would be obsolete.

(The way FreeRTOS does it, is way more intuitive for me: https://www.freertos.org/Embedded-RTOS-Queues.html)

Best Regards,

Dominik

Von: Cufi, Carles <Carles.Cufi@...>
Gesendet: Freitag, 28. August 2020 16:29
An: Weber, Dominik <dominik.weber@iis.fraunhofer.de>; users@...
Betreff: RE: FIFO is not empty after getting all data items; reference pointer still points to another item

Hi Dominik,

>. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

FIFOs do not copy the contents of the message, they only store the pointer in a linked list. Maybe this is not clear enough in the documentation, please consider sending a Pull Request enhancing the doc.

If you need the kernel to copy the contents of your message for you, you can use Message Queues:

https://docs.zephyrproject.org/latest/reference/kernel/data_passing/message_queues.html

Thanks,

Carles

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 28 August 2020 13:22
To: users@...
Subject: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

Hey everyone,

I’m currently having problems when putting items to a FIFO. As long as I put data items to my FIFO queue, everything is ok and works as expected. If I stop putting data to the queue, the reading thread continues reading the last data item out of the queue over and over again, although the queue should be empty but is not (k_fifo_is_empty() says it’s not empty).

There’s a writing and a reading thread in my software project.

I have the following data item, defined in the header file of the reading thread:

typedef struct

{

void *fifoReserved; ///< 1st word reserved for use by fifo

int data1;

int data2;

} s_data_item_fifo_ecg_t;

The writing thread is like:

(This is a static variable in the software module)

static s_data_item_fifo_ecg_t ecgDataStruct; ///< This data item contains the ecg information to put to the data fifo.

(Inside the thread)

while (1)

{

/* Thread will be unready until signal was raised, signal will be raised when data ready interrupt comes */

k_poll(daEvents, 1, K_FOREVER);

/* Reset signal */

daEvents[0].signal->signaled = 0;

daEvents[0].state = K_POLL_STATE_NOT_READY;

/* …get data from hardware chip here… */

ecgDataStruct.data1 = …;

ecgDataStruct.data2 = …;

dataProcessingPutFifoECG(&ecgDataStruct);

}

The last function is part of the reading thread software module and just puts the item to the queue with k_fifo_put().

The reading thread is like:

(This is a static variable in the software module)

static struct k_fifo dpFifoECG; ///< FIFO structure for handling incoming ECG data

There is an init function, where this is called:

k_fifo_init(&dpFifoECG);

s_data_item_fifo_ecg_t *fifoDataECG;

while (1)

{

/* Get data from queue. */

fifoDataECG = k_fifo_get(&dpFifoECG, K_FOREVER);

printk("%d,%d\n", fifoDataECG->data1, fifoDataECG->data2);

}

I checked the print outputs with a terminal program and realized that the data is still printed, even if I stop the measurement and stop putting data to the queue, which means that the program is not waiting at k_fifo_get() as expected. It just continues reading the last item which should be removed from the queue.

When I have a look at the fifoReserved pointer for these unwanted items, I see that the pointer is always the same and not NULL. Shouldn’t the pointer be NULL if there are no more items in the list?

This is really driving me crazy.

Both threads do have a maximum memory thread stack size of 8kB.

The priorities are -2 for the writing thread (implements SPI communication) and 1 for the reading thread. (There are three threads running on the system, excluding main thread and idle thread).

A general question:

For me, it is not really clear, if a data item is passed by copy or by reference to the fifo queue. I assume, the items are passed by reference, since I faced some serious problems when passing data items from an ISR, which are lying on the ISR stack. The content of the data item was sometimes different after reading the item compared to when the item was putted to the queue. The solution to this problem was to define a static data item on the memory heap of the software module and to only adjust the data of the same item and put it again to the queue. This seems very unintuitive to me, since I put the same item to the queue over and over again, only with different content. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

My setup:

Zephyr 2.3 Build 99
Nordic nRF52840 DK
Segger J-Link OB-SAM3U128-V2-NordicSemi
Eclipse 2019-09
Python 3.8.3
West 0.7.2
C compiler GNU 9.2.1

Thanks for your help!

Re: FIFO is not empty after getting all data items; reference pointer still points to another item

Weber, Dominik <dominik.weber@...>

#2235

Hi Carles,

thanks for your reply. This solved my problem.

But why does Zephyr not copy the items to the list? For me, there’s absolutely no reason to NOT copy data items to a queue . It runs the risk to…

· … put data items to the queue which are on the stack of a function or an ISR. Thus, these elements would be not valid anymore when the function returns. This is a major security issue, since you won’t be able to recognize the error until it will be overwritten randomly in memory…

· … put the same data item several times to the queue which has the same memory address but different content (which was actually my problem)

Furthermore I would need a separate buffer to store my queue items, if I only put pointers to the queue. So one of the main features of a queue would be obsolete.

(The way FreeRTOS does it, is way more intuitive for me: https://www.freertos.org/Embedded-RTOS-Queues.html)

Best Regards,

Dominik

Von: Cufi, Carles <Carles.Cufi@...>
Gesendet: Freitag, 28. August 2020 16:29
An: Weber, Dominik <dominik.weber@iis.fraunhofer.de>; users@...
Betreff: RE: FIFO is not empty after getting all data items; reference pointer still points to another item

Hi Dominik,

>. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

FIFOs do not copy the contents of the message, they only store the pointer in a linked list. Maybe this is not clear enough in the documentation, please consider sending a Pull Request enhancing the doc.

If you need the kernel to copy the contents of your message for you, you can use Message Queues:

https://docs.zephyrproject.org/latest/reference/kernel/data_passing/message_queues.html

Thanks,

Carles

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 28 August 2020 13:22
To: users@...
Subject: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

Hey everyone,

I’m currently having problems when putting items to a FIFO. As long as I put data items to my FIFO queue, everything is ok and works as expected. If I stop putting data to the queue, the reading thread continues reading the last data item out of the queue over and over again, although the queue should be empty but is not (k_fifo_is_empty() says it’s not empty).

There’s a writing and a reading thread in my software project.

I have the following data item, defined in the header file of the reading thread:

typedef struct

{

void *fifoReserved; ///< 1st word reserved for use by fifo

int data1;

int data2;

} s_data_item_fifo_ecg_t;

The writing thread is like:

(This is a static variable in the software module)

static s_data_item_fifo_ecg_t ecgDataStruct; ///< This data item contains the ecg information to put to the data fifo.

(Inside the thread)

while (1)

{

/* Thread will be unready until signal was raised, signal will be raised when data ready interrupt comes */

k_poll(daEvents, 1, K_FOREVER);

/* Reset signal */

daEvents[0].signal->signaled = 0;

daEvents[0].state = K_POLL_STATE_NOT_READY;

/* …get data from hardware chip here… */

ecgDataStruct.data1 = …;

ecgDataStruct.data2 = …;

dataProcessingPutFifoECG(&ecgDataStruct);

}

The last function is part of the reading thread software module and just puts the item to the queue with k_fifo_put().

The reading thread is like:

(This is a static variable in the software module)

static struct k_fifo dpFifoECG; ///< FIFO structure for handling incoming ECG data

There is an init function, where this is called:

k_fifo_init(&dpFifoECG);

s_data_item_fifo_ecg_t *fifoDataECG;

while (1)

{

/* Get data from queue. */

fifoDataECG = k_fifo_get(&dpFifoECG, K_FOREVER);

printk("%d,%d\n", fifoDataECG->data1, fifoDataECG->data2);

}

I checked the print outputs with a terminal program and realized that the data is still printed, even if I stop the measurement and stop putting data to the queue, which means that the program is not waiting at k_fifo_get() as expected. It just continues reading the last item which should be removed from the queue.

When I have a look at the fifoReserved pointer for these unwanted items, I see that the pointer is always the same and not NULL. Shouldn’t the pointer be NULL if there are no more items in the list?

This is really driving me crazy.

Both threads do have a maximum memory thread stack size of 8kB.

The priorities are -2 for the writing thread (implements SPI communication) and 1 for the reading thread. (There are three threads running on the system, excluding main thread and idle thread).

A general question:

For me, it is not really clear, if a data item is passed by copy or by reference to the fifo queue. I assume, the items are passed by reference, since I faced some serious problems when passing data items from an ISR, which are lying on the ISR stack. The content of the data item was sometimes different after reading the item compared to when the item was putted to the queue. The solution to this problem was to define a static data item on the memory heap of the software module and to only adjust the data of the same item and put it again to the queue. This seems very unintuitive to me, since I put the same item to the queue over and over again, only with different content. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

My setup:

Zephyr 2.3 Build 99
Nordic nRF52840 DK
Segger J-Link OB-SAM3U128-V2-NordicSemi
Eclipse 2019-09
Python 3.8.3
West 0.7.2
C compiler GNU 9.2.1

Thanks for your help!

Re: Password Protection for Shell #uart #api

Chruściński, Krzysztof

#2234

Hi Dave,

I think you could try to look into selecting root command feature. Create dummy command with only “login” subcommand. Set this dummy command during system startup (shell_set_root_command(“dummy_cmd”) as root command. Then to enable all commands reset root command on login ( shell_set_root_cmd(NULL)). It can give a notion of shell protection. There is one thing though: select command and a key shortcut which is equivalent of shell_set_root_cmd(NULL) that must be disabled (CONFIG_SHELL_CMDS_SELECT=n).

Regards,

Krzysztof

Show quoted text

From: users@... <users@...> On Behalf Of dave via lists.zephyrproject.org
Sent: Tuesday, September 15, 2020 10:17 PM
To: users@...
Subject: [Zephyr-users] Password Protection for Shell #uart #api

Hello,
I'm quite new to Zephyr, so I may have missed this, but I can't seem to find an easy way to add a simple password protection wall for the shell commands. I don't need or expect a full user model with permissions, just a simple "root" style password that can hide the commands until it is entered. Assuming I connect my device over USB and bring up the shell as a serial console, I can see that I have full access to all the shell commands without any protections. I often design products that use the shell/CLI as an interface to verify the system during manufacturing, as well as deal with systems that may have been bricked in the field, so it's something I'd like to continue using - but I don't want this to be wide open to users.

I could imagine using the API to create a command, like say "login", with a password argument field - but maybe there is a more elegant way?

Thanks in advance for the help!

Cheers,
Dave MacLeod

Re: How to resolve FATAL ERROR that displayed when I edited, modified some files.

Dicek Bear

#2233

Dear Zephyr Users, Developers,

Thank you for good support.

I did not know that header files and c-sources comments can not include any irregular code that represent some languages' characters except alphabet.

Now I replaced all comments to the alphabet. Then the problem is solved.

Thank you and best regards,

Dicek Bear.

2020年9月11日(金) 12:20 Dicek Bear via lists.zephyrproject.org <dicek334=gmail.com@...>:

Show quoted text

Dear Zephyr Users, Developers,

I am a beginner of Zepher OS, so it is too difficult to analyze the following problem.
Please teach me how to resolve it.

First step,
I install the development environment as following "Getting Started Guide "https://docs.zephyrproject.org/latest/getting_started/index.html".
Then I try some samples and demos, 'hello_world', 'blinky', 'Button','console_getchar() Sample Application','console_getline() Sample Application'
and so on. The build command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Second step,
I edit, modify some header files and c-source files, then I rebuild 'hello_world' sample again. It is no problem.
The rebuild command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Third step,
I clean the build files. The clean command is "$west build -t clean". It is no problem.

Fourth step,
I try to build again with the same build command "$ west build -p auto -b atsamr21_xpro samples/hello_world/". It causes 'FATAL ERROR".
The following is the displayed messages.

==================================================================================================================================
vagrant@ubuntu2004:~/zephyrproject/zephyr$ west build -p auto -b atsamr21_xpro samples/hello_world/
[1/122] Preparing syscall dependency handling
[3/122] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
FAILED: zephyr/misc/generated/syscalls.json zephyr/misc/generated/struct_tags.json
cd /home/vagrant/zephyrproject/zephyr/build/zephyr && /usr/bin/python3.8 /home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py --include /home/vagrant/zephyrproject/zephyr/include --include /home/vagrant/zephyrproject/zephyr/drivers --include /home/vagrant/zephyrproject/zephyr/subsys/net --json-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/syscalls.json --tag-struct-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json
Traceback (most recent call last):
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 153, in <module>
    main()
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 132, in main
    syscalls, tagged = analyze_headers(args.include)
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 80, in analyze_headers
    contents = fp.read()
File "/usr/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8f in position 16151: invalid start byte
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/vagrant/zephyrproject/zephyr/build
==================================================================================================================================

Are there any rules to edit, modify header files and c-source files ?.

Thank you and best regards,
Dicek Bear.

Password Protection for Shell #uart #api

dave@...

#2232

Hello,
I'm quite new to Zephyr, so I may have missed this, but I can't seem to find an easy way to add a simple password protection wall for the shell commands. I don't need or expect a full user model with permissions, just a simple "root" style password that can hide the commands until it is entered. Assuming I connect my device over USB and bring up the shell as a serial console, I can see that I have full access to all the shell commands without any protections. I often design products that use the shell/CLI as an interface to verify the system during manufacturing, as well as deal with systems that may have been bricked in the field, so it's something I'd like to continue using - but I don't want this to be wide open to users.

I could imagine using the API to create a command, like say "login", with a password argument field - but maybe there is a more elegant way?

Thanks in advance for the help!

Cheers,
Dave MacLeod

API meeting: agenda

Carles Cufi

#2231

Hi all,

Another special agenda for today:

- Modbus: https://github.com/zephyrproject-rtos/zephyr/pull/26516
- In order to help with the 2.4 release we will go through bugs labeled API or drivers and try to clean up or assign as many as we can.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

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: Requesting Bug list for ZephyrProject release 1.14.0

Carles Cufi

#2230

Hi Harish,

Best I can think of for that is to use a filter in GitHub to see all issues (open and closed) that target the next 1.14.3 release:

https://github.com/zephyrproject-rtos/zephyr/issues?q=+is%3Aissue+milestone%3Av1.14.3+

Carles

Show quoted text

From: Harish KothandaRaman <harish.kothandaraman@...>
Sent: 14 September 2020 14:47
To: Cufi, Carles <Carles.Cufi@...>
Cc: users@...; Arjun Chinta <arjun@...>
Subject: Re: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

Hello Carles,

Thanks for the pointers. I really appreciate your help.

From the above link it is possible to get the list of issue that has been fixed in version 1.14.x , but is it possible for us to know what where the issue that was pending when v1.14.x was released?

Thanks,

Harish K

On Sep 14, 2020, at 7:32 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Harish,

You can browse the issues that were addressed in the 1.14.x releases here:

https://docs.zephyrproject.org/1.14.1/releases/release-notes-1.14.html

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.14.2

Then there’s also the vulnerability list:

https://docs.zephyrproject.org/latest/security/vulnerabilities.html

Thanks,

Carles

From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

Hello,

This is Harish Working for NupulseCV an medical device manufacturer.

We have used the Zephyr project (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development.

As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.

For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.

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

But it would be really helpful for us to understand what were the pending issues for nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards

Harish K

Re: Requesting Bug list for ZephyrProject release 1.14.0

Harish KothandaRaman <harish.kothandaraman@...>

#2229

Hello Carles,

Thanks for the pointers. I really appreciate your help.

From the above link it is possible to get the list of issue that has been fixed in version 1.14.x , but is it possible for us to know what where the issue that was pending when v1.14.x was released?

Thanks,

Harish K

Show quoted text

On Sep 14, 2020, at 7:32 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Harish,

You can browse the issues that were addressed in the 1.14.x releases here:
https://docs.zephyrproject.org/1.14.1/releases/release-notes-1.14.html
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.14.2

Then there’s also the vulnerability list:
https://docs.zephyrproject.org/latest/security/vulnerabilities.html

Thanks,

Carles

From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

Hello,

This is Harish Working for NupulseCV an medical device manufacturer.
We have used the Zephyr project (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development.
As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.
For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.
https://github.com/zephyrproject-rtos/zephyr/issues'
But it would be really helpful for us to understand what were the pending issues for nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards
Harish K

Re: Requesting Bug list for ZephyrProject release 1.14.0

Carles Cufi

#2228

Hi Harish,

You can browse the issues that were addressed in the 1.14.x releases here:

https://docs.zephyrproject.org/1.14.1/releases/release-notes-1.14.html

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.14.2

Then there’s also the vulnerability list:

https://docs.zephyrproject.org/latest/security/vulnerabilities.html

Thanks,

Carles

Show quoted text

From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

Hello,

This is Harish Working for NupulseCV an medical device manufacturer.

We have used the Zephyr project (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development.

As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.

For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.

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

But it would be really helpful for us to understand what were the pending issues for nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards

Harish K

Re: Custom linker script for module #api

EugKrashtan

#2227

Ok, solution found. Adding zephyr_linker_sources(SECTIONS custom-sections.ld) into cmakelists.txt inside module folder giver required flexibility.
Thanks!

Custom linker script for module #api

EugKrashtan

#2226

Hi.
My custom module requires an additional ROM section. Is it possible to define CONFIG_CUSTOM_LINKER_SCRIPT for module only without adding this option to prj.conf file?

WBR,
Eugene

Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Erwan Gouriou

#2225

Thanks Brix.

Helge, FYI, you might be interested in https://github.com/zephyrproject-rtos/zephyr/issues/27985 that will work around the issue for V2.4.0.

BR
Erwan

Show quoted text

On Wed, 9 Sep 2020 at 21:48, Henrik Brix Andersen <henrik@...> wrote:

Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards,
Brix
--
Henrik Brix Andersen

> On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@...> wrote:
>
> Hi Helge,
>
> Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
> board pinmux init: PRE_KERNEL_1
> gpio init: POST_KERNEL
> So, what seems strange also is that it had effect in v2.3.0.
>
> Anyway, the problem still stands.
>
> I don't see a particular reason you wouldn't not be allowed to make this call.
> So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
> I can't tell if there is a reason it is not the case already.
>
> BR
> Erwan
>
>
>
> On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@...> wrote:
> Hi.
>
> I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.
>
> I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:
>
> static int pinmux_stm32_init(const struct device *port)
> {
> ARG_UNUSED(port);
> stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));
>
> const struct device *porti = device_get_binding("GPIOI");
> gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
> gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);
>
> return 0;
> }
>
> This works with v2.3.0.
> With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.
>
> During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.
>
> Questions:
> 1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
> 2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)
>
> Thanks,
> Helge
>
>

How to resolve FATAL ERROR that displayed when I edited, modified some files.

Dicek Bear

#2224

Dear Zephyr Users, Developers,

I am a beginner of Zepher OS, so it is too difficult to analyze the following problem.

Please teach me how to resolve it.

First step,

I install the development environment as following "Getting Started Guide "https://docs.zephyrproject.org/latest/getting_started/index.html".

Then I try some samples and demos, 'hello_world', 'blinky', 'Button','console_getchar() Sample Application','console_getline() Sample Application'

and so on. The build command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Second step,

I edit, modify some header files and c-source files, then I rebuild 'hello_world' sample again. It is no problem.

The rebuild command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Third step,

I clean the build files. The clean command is "$west build -t clean". It is no problem.

Fourth step,

I try to build again with the same build command "$ west build -p auto -b atsamr21_xpro samples/hello_world/". It causes 'FATAL ERROR".

The following is the displayed messages.

==================================================================================================================================

vagrant@ubuntu2004:~/zephyrproject/zephyr$ west build -p auto -b atsamr21_xpro samples/hello_world/
[1/122] Preparing syscall dependency handling

[3/122] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
FAILED: zephyr/misc/generated/syscalls.json zephyr/misc/generated/struct_tags.json
cd /home/vagrant/zephyrproject/zephyr/build/zephyr && /usr/bin/python3.8 /home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py --include /home/vagrant/zephyrproject/zephyr/include --include /home/vagrant/zephyrproject/zephyr/drivers --include /home/vagrant/zephyrproject/zephyr/subsys/net --json-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/syscalls.json --tag-struct-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json
Traceback (most recent call last):
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 153, in <module>
    main()
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 132, in main
    syscalls, tagged = analyze_headers(args.include)
File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 80, in analyze_headers
    contents = fp.read()
File "/usr/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8f in position 16151: invalid start byte
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/vagrant/zephyrproject/zephyr/build

==================================================================================================================================

Are there any rules to edit, modify header files and c-source files ?.

Thank you and best regards,

Dicek Bear.

Build fails : arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

Hanumesha Ks <hanumesha.ks@...>

#2223

Hi Zephyr Users,

I tried to execute following command,

\zephyrproject\zephyr>west build -b qemu_cortex_a53 -d build\hello_world samples\hello_world

by v2.3.0 release on Windows-10 with gcc-arm-none-eabi-9-2019-q4-major-win32

but my build fails with error arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

Build fails screenshot pasted below.

As per the gcc AArch64 “-mabi” Permissible values are -mabi=ilp32 and -mabi=lp64 more info in below link.

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options

Please guide me to resolve this issue ?

Best Regards

Hanumesha KS

Software engineer

NXP – Bangalore

Re: Flash two firmware in flash and jump from one address to another #flash #nrf52480

Nikos Karamolegkos

#2222

Hello, after all I am flashing the base firmware (first app) into 0x0 address and then using the CONFIG_FLASH_LOAD_OFFSET=0x20000 to the proj.conf of the second app I am flashing the second firmware in the 0x20000 address. Therefore, when I press a button from the first app I can jump to the second firmware. The only issue now is that I would like to update the start address to 0x20000 before the "jump" (in this way if I press reset the second app will boot). I have looked to the flash configs of zephyr but I have not found something useful. Any ideas?

Re: Direct ISR support on ARC

Justin Huang

#2221

Thank you Ruud for sharing and sorry for replying late.

You nail it: I was checking Zephyr 2.0.0. I will get the latest copy and give it a try.

Many thanks again,

Justin

Show quoted text

From: users@... <users@...> on behalf of Ruud Derwig <ruud.derwig@...>
Sent: Monday, August 31, 2020 2:19 AM
To: Justin Huang <justin.y.huang@...>; users@... <users@...>
Subject: Re: [Zephyr-users] Direct ISR support on ARC

Hi Justin,

What version are you using? ARC support for direct interrupts was added in v2.1

(and note that Z_ARCH_IRQ_DIRECT_CONNECT was renamed to ARCH_IRQ_DIRECT_CONNECT).

Regards,

Ruud.

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, August 29, 2020 2:45 AM
To: users@...
Subject: [Zephyr-users] Direct ISR support on ARC

Hi,

It appears to me that there is no support of 'direct ISR' by Zepher for the ARC processors: I do not see the definition of Z_ARCH_IRQ_DIRECT_CONNECT in the irq.h for ARC.

Could someone please share why it is not supported?

Thanks,
Justin

Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Henrik Brix Andersen

#2220

Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards, 
Brix
--
Henrik Brix Andersen

Show quoted text

On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Helge,

Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.

Anyway, the problem still stands.

I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.

BR
Erwan



On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@nortekgroup.com> wrote:
Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1.  Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2.  If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge

Requesting Bug list for ZephyrProject release 1.14.0

Harish KothandaRaman <harish.kothandaraman@...>

#2219

Hello,

This is Harish Working for NupulseCV an medical device manufacturer.

We have used the Zephyr project (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development.

As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.

For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.

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

But it would be really helpful for us to understand what were the pending issues for nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards

Harish K