Date   

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

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

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

 

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(daEvents1, 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->data1fifoDataECG->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@...>
 

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(daEvents1, 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->data1fifoDataECG->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
 

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

 

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
 

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

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

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
 


Re: Requesting Bug list for ZephyrProject release 1.14.0

Carles Cufi
 

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

 

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:

 

 

Then there’s also the vulnerability list:

 

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.

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

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:
 
 
Then there’s also the vulnerability list:
 
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.
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
 

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.

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
 

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
 

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
 

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

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
 

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

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
 

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
 

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


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
 

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

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.
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: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Erwan Gouriou
 

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


561 - 580 of 2788