Date   

Re: #mqtt Failed to obtain RX buffer #mqtt #api

Jukka Rissanen
 

Hi Erik,

you are running out of RX network buffers. Try to increase the value of
CONFIG_NET_BUF_RX_COUNT
and optionally
CONFIG_NET_PKT_RX_COUNT
options.

Cheers,
Jukka

On Sun, 2020-04-19 at 23:58 -0700, erik.samyn@gmail.com wrote:
Hi,

I'm implementing mqtt on an nucleo stm32 board (stm32f767zi). The
communication from the broker seemed to work OK at first, however
when stressing the communication a bit the next error appears
multiple times in the log:
==> "<err> eth_stm32_hal: Failed to obtain RX buffer".

What can be the cause of this?

Kind regards

Erik Samyn


API meeting cancelled today

Carles Cufi
 

Hi all,

I have cancelled the API meeting today due to my lack of availability today. To my knowledge, we did not have any pressing matters to discuss, but as always please let me know or add the issue or PR to the API review/cleanup/rework GitHub project in order to be discussed next week.

Apologies for the short notice.

Regards,

Carles


#mqtt Failed to obtain RX buffer #mqtt #api

erik.samyn@...
 

Hi,

I'm implementing mqtt on an nucleo stm32 board (stm32f767zi). The communication from the broker seemed to work OK at first, however when stressing the communication a bit the next error appears multiple times in the log:
==> "<err> eth_stm32_hal: Failed to obtain RX buffer".

What can be the cause of this?

Kind regards 

Erik Samyn


Re: #api #api

Andy Ross
 

On 4/16/2020 3:20 PM, r.gokool@gmail.com wrote:
Hello, I am new to Zephyr. I have a need to write code that runs on both RTOS and linux. It is structured as an event loop that can monitor sockets, local queues and timers for Linux. When looking at the APIs in the RTOS I noticed that there is no common poll API. Isee k_poll() can poll kernel objects while zsock_poll() can poll sockets. Is there a way to monitor sockets and kernel objects using the same event loop?
If not I am curious to understand why the API deviates from Linux. Is there an RTOS specific benefit to splitting the poll api this way?
Mostly for the same sorts of reasons that poll() in Linux can't wait on a POSIX condition variable or futex.

The zsock_poll() implementation is designed to work the way it works on existing Berkley sockets code, and it understands sockets in the network layer. The kernel k_poll() abstraction understands existing kernel objects, which aren't sockets.

That said, it wouldn't be impossible to make these interoperate. The k_poll_event object has a "signal" type which allows arbitrary external code to provide wakeup notifications to threads blocked in k_poll(). Someone could write a constructor for such a k_poll_event in the network layer without too much trouble, I think.

It's possible we could remove the zsock_poll() implementation entirely and replace it with this sort of wrapper around k_poll, actually. But I haven't looked at that implementation and don't know what would be involved or what the costs might be.

Andy


#api #api

r.gokool@...
 

Hello, I am new to Zephyr. I have a need to write code that runs on both RTOS and linux. It is structured as an event loop that can monitor sockets, local queues and timers for Linux. When looking at the APIs in the RTOS I noticed that there is no common poll API. I see k_poll() can poll kernel objects while zsock_poll() can poll sockets. Is there a way to monitor sockets and kernel objects using the same event loop?
If not I am curious to understand why the API deviates from Linux. Is there an RTOS specific benefit to splitting the poll api this way?

Input and suggestions requested. Thanks.


Build size of bluetooth and ip stack #bluetooth #nrf51822

mdl.mailme@...
 

Hi, 

i am trying to build the bluetooth/ipsp/ example for the nrf51, but the build fails because the SRAM overflows (50kB usage with 32kB available on the nRF51). Also, the Flash usage is 98%. I checked the zephyr_prebuilt.map file to see the sizes of the single modules/libraries. It shows that only the bluetooth and ip modules use around 180kB of Flash and 32kB of SRAM. Is it normal for it to be this large? If yes, is there a possibility of reducing the size of those modules?

I attached the zephyr_prebuilt.map file, the output of my self built parser showing the ROM and RAM usage of the single modules and the build output.

Kind regards,

Marco Liess


Re: getting started with ssd1306 shield

Erwan Gouriou
 

Hi Trevor,

What is the error reported ?

Erwan

On Tue, 14 Apr 2020 at 16:06, Trevor Clarke <pythonpimp@...> wrote:
I'm new to zephyr and I'm trying to get a 128x32 SSD1306 display working with a stm32 black pill and I'm having trouble.
My prj.conf has CONFIG_DISPLAY=y
My CMakeLists.txt has set(SHIELD ssd1306_128x32) before the boilerplate include.

When configuring I get a "Label or path arduino_i2c not found" so I tried adding "arduino_i2c=&i2c1" to my app overlay file and that didn't help.

Am I missing something in my app code? Or do I need to modify the shield code to accommodate stm32? If so, where would I get started with that?


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


getting started with ssd1306 shield

Trevor Clarke
 

I'm new to zephyr and I'm trying to get a 128x32 SSD1306 display working with a stm32 black pill and I'm having trouble.
My prj.conf has CONFIG_DISPLAY=y
My CMakeLists.txt has set(SHIELD ssd1306_128x32) before the boilerplate include.

When configuring I get a "Label or path arduino_i2c not found" so I tried adding "arduino_i2c=&i2c1" to my app overlay file and that didn't help.

Am I missing something in my app code? Or do I need to modify the shield code to accommodate stm32? If so, where would I get started with that?


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


Re: API meeting: agenda

Carles Cufi
 

Two additional items:

- DAC API proposal
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/21805

- Auth API location
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/23465

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via lists.zephyrproject.org
Sent: 13 April 2020 19:33
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: julien.dascenzio@paratronic.fr; jukka.rissanen@linux.intel.com;
johan.hedberg@intel.com; Andersson, Joakim
<Joakim.Andersson@nordicsemi.no>
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Tomorrow's topics:

- Proposal to unify the "forever" timeout constant across subsystems
that take milliseconds as an input parameter
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24267

- RTC API proposal review after comments from the author
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/

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


MCP2515 Interrupt #can

turboaffe@...
 

Hello everybody, this is my first post.
I have a problem with the drivers/can/can_mcp2515.c interrupt configuration/the mcp2515 driver implementation.
I would like to send a can message with the can_send function. On my board, a stm32 is connected to the mcp2515.
The message is sent, i see it on the bus via candump, and my logic analyzer shows a falling edge on the mcp2515 interrupt output as soon as the mcp2515 is done with sending.
The OS does not react on that falling edge, and my program is stuck on the blocking can_send function.
I discovered that the whole thing works if i change the interrupt edge configuration/gpio flags as follows in can_mcp2515.c, lines 860 to 862:

From: if (gpio_pin_interrupt_configure(dev_data->int_gpio, dev_cfg->int_pin, GPIO_INT_EDGE_TO_ACTIVE)) { return -EINVAL; }
To: if (gpio_pin_interrupt_configure(dev_data->int_gpio, dev_cfg->int_pin, GPIO_INT_EDGE_TO_INACTIVE)) { return -EINVAL; }

Can somebody point me to somebody who I could discuss this problem with? I am not sure if this is a bug or how it can work on the other boards, like the DF Robot CAN Shield one.

Thank you!


NFC Support #nxp #i2c #nvs

nanjunneo@...
 

Hello guys,

I would like to implement an application with NFC tag reader via NXP PN532 or other NFC controllers, which communicates with board via I2C, is there any suggestion or sample to follow how to start it?

Thanks for kind reply in advance.

Best regards,
Neo


API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow's topics:

- Proposal to unify the "forever" timeout constant across subsystems that take milliseconds as an input parameter
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24267

- RTC API proposal review after comments from the author
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/

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: issues with devicetree in 2.2

Bolivar, Marti
 

"Trevor Clarke via lists.zephyrproject.org"
<pythonpimp=gmail.com@lists.zephyrproject.org> writes:

'm using Zephyr 2.2 for stm32 through platformio. I'm trying to use the
newer device tree API to configure hardware through an overlay.
I've got an overlay with:

&usart3 { current-speed = <31250>; };
/ { aliases { midi-port = &usart2; }; };

In devicetree_unfixed.h I get defines like DT_ALIAS_MIDI_PORT_BASE_ADDRESS
so I know my overlay is being processed.

In my C code I do:

#define MIDI_DEV DT_ALIAS(midi_port)
...
struct device* midiin = device_get_binding(MIDI_DEV);
In the zephyr master branch, it would be DT_LABEL(MIDI_DEV).

https://docs.zephyrproject.org/latest/guides/dts/howtos.html#get-a-struct-device-from-a-devicetree-node

However: this won't work in 2.2.



When I compile (complete clean and rebuild which re-runs cmake, etc.) I see:

warning: implicit declaration of function 'DT_ALIAS';

A search through my build artifacts and through the zephyr source shows no
definie for DT_ALIAS. I'm following the examples in the documentation. Am I
missing something?
This new DT API is only in the master branch, not Zephyr 2.2.

Since you're on 2.2, use the old API:

https://docs.zephyrproject.org/2.2.0/guides/dts/index.html

HTH,
Marti


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@csh.rit.edu
http://www.csh.rit.edu/~retrev/


issues with devicetree in 2.2

Trevor Clarke
 

'm using Zephyr 2.2 for stm32 through platformio. I'm trying to use the newer device tree API to configure hardware through an overlay. 
I've got an overlay with:

&usart3 { current-speed = <31250>; };
/ { aliases { midi-port = &usart2; }; };

In devicetree_unfixed.h I get defines like DT_ALIAS_MIDI_PORT_BASE_ADDRESS so I know my overlay is being processed.

In my C code I do:

#define MIDI_DEV DT_ALIAS(midi_port)
...
struct device* midiin = device_get_binding(MIDI_DEV);


When I compile (complete clean and rebuild which re-runs cmake, etc.) I see:

warning: implicit declaration of function 'DT_ALIAS';

A search through my build artifacts and through the zephyr source shows no definie for DT_ALIAS. I'm following the examples in the documentation. Am I missing something?

--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


HWINFO API clarification

Steven Slupsky <sslupsky@...>
 

There were two recent issues (#23444, #24103) that identified a byte ordering issue with the hwinfo API.  A PR (#24203) has been submitted to clarify the hwinfo API identifier data structure.  This clarification has resulted in changes to the sam0 and nordic drivers.  Moreover, some components that depend on the hwinfo api may have implemented work arounds for this issue. Issue #24103 identified the USB identifier was affected and issue #23444 identified Bluetooth may be affected.

A summary of the commit is provided below.  Please note other drivers may be affected by this issue.
  
The identifier data structure for hwinfo drivers is clarified.  Drivers are responsible for ensuring that the identifier data structure is a sequence of bytes. The returned ID value is not supposed to be interpreted based on  vendor-specific assumptions of byte order and should express the identifier as a raw byte sequence.

The changes have an impact on users that use the hwinfo API to identify their devices.

The sam0 driver byte swaps each 32 bit word of the 128 bit identifier to big endian. The nordic driver byte swaps the entire 64 bit word to big endian.


Zephyr networking testing in LAVA, was: Re: Network forum agenda

Paul Sokolovsky
 

Hello,

On Mon, 6 Apr 2020 21:44:27 +0300
"Paul Sokolovsky via lists.zephyrproject.org"
<paul.sokolovsky=linaro.org@lists.zephyrproject.org> wrote:

[]

If there is time, I'd like to share some progress on setting up CI
for network testing with real hardware, on which I've been working
last time.
I appreciate being able to present my work quickly and the discussion
of testing matters which followed. As it was just a quick spoken
presentation, I'd like to share a few links showing more details, with
the idea to keep wider community in loop of testing efforts around
Zephyr.

So, in this work Linaro LITE team uses the LAVA system (Linaro
Automation and Validation Architecture), which is an open source
project at https://www.lavasoftware.org/ (we run a particular
deployment at https://lite.validation.linaro.org/).

How it works is that we build Zephyr tests/samples in Jenkins (using
the standard Zephyr "sanitycheck" tool), then submit binaries to LAVA,
accompanied by a "test job definition", which is a YAML file like
https://lite.validation.linaro.org/scheduler/job/960800/multinode_definition#defline1 .

The job is then being run, with log of interaction recorded and
analyzed for success/failure. In this case it's a networking test which
involves 2 "nodes": a DUT (device under test) per se (FRDM-K64F board):
https://lite.validation.linaro.org/scheduler/job/960800.0 and a docker
container representing "a host":
https://lite.validation.linaro.org/scheduler/job/960800.1#L56 . Here,
the actual test interaction happens on the host, which starts with
easy-pinging a device, then pings more with full Ethernet frames, then
does a "poorman's flood ping" of pinging 1000 times with full packets
and 10ms interval. All these actions are encoded in the YAML definition
and are easily reconfigurable.

LAVA checks that individual actions outcome satisfies success criteria
and records overall results, e.g.
https://lite.validation.linaro.org/results/960801/0_ping .

The biggest value of such a system would come from early notifications
of failures, and ability to compare results over time. The best ways to
achieve that is so far under investigation (the whole work is largely a
prototype at this stage).

As discussed yesterday, we all by now should be aware that "Zephyr
testing" bastion is being stormed by multiple stakeholders in different
ways, and I just wanted to share Linaro's approach and progress with
wider community. While the primary drivers for this works are
requirements of our members interested in Zephyr, who already adopted
the LAVA system, the work itself is open-source, results are public, and
hopefully useful for a wider Zephyr community. (And different teams
working on testing definitely should reuse results of each other's work,
and further the best practices for making Zephyr more testable and
quality-assured).


Thanks,
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 cancelled today

Carles Cufi
 

Hi all,

Due to several people being away and needing a bit more time to discuss some of the items offline I am cancelling this week's API meeting.
Next week the meeting will take place as usual.

Thanks,

Carles


Re: Network forum agenda

Paul Sokolovsky
 

Hello,

On Mon, 06 Apr 2020 15:01:40 +0300
"Jukka Rissanen" <jukka.rissanen@linux.intel.com> wrote:

Hi all,

There is a network forum meeting tomorrow 7 Apr at 8AM PDT / 17.00 CET

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#networking-forum
Thanks for the reminder, appreciated!

Preliminary agenda:

* Network stack status

* k_timeout_t changes in networking stack. Initial PR can be found at
https://github.com/zephyrproject-rtos/zephyr/pull/24071

* Review help needed for GSM 07.10 mux PR at
https://github.com/zephyrproject-rtos/zephyr/pull/23422

If you have anything you want to discuss, please let me know.
Will there be any status update on TCP2? I see recently there're
multiple patches from different developers, so would be nice to hear a
summary of where it stands and if it's ready to be explored by wider
community.

If there is time, I'd like to share some progress on setting up CI
for network testing with real hardware, on which I've been working last
time.


Cheers,
Jukka

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


Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow 7 Apr at 8AM PDT / 17.00 CET

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#networking-forum

Preliminary agenda:

* Network stack status

* k_timeout_t changes in networking stack. Initial PR can be found at
https://github.com/zephyrproject-rtos/zephyr/pull/24071

* Review help needed for GSM 07.10 mux PR at
https://github.com/zephyrproject-rtos/zephyr/pull/23422

If you have anything you want to discuss, please let me know.


Cheers,
Jukka


Re: Assert in sched.c

Boie, Andrew P
 

Check for stack overflows, enable CONFIG_STACK_SENTINEL if you don't have an MPU.

 

From: users@... <users@...> On Behalf Of erik.johnson@...
Sent: Wednesday, April 1, 2020 4:24 PM
To: users@...
Subject: [Zephyr-users] Assert in sched.c

 

I'm running v2.1.99-ncs1, which is a downstream minimal fork provided by Nordic Semiconductor. For the purposes of this bug, I can't find any difference between their code and the upstream Zephyr source.

There's no tag for it, but we're using the nRF9160 from Nordic.

 

Anyway, I'm having an assertion in the tick sleep code. It seems that the assert is trying to make sure the resuming context isn't marked as "suspended", but somehow that assertion is getting hit...

 

I'm unfortunately just not familiar enough with the kernel yet to know what's going on, so I was hoping to get some help on it. In particular, if there are any kind of known "gotcha" cases that would cause this assertion.

 

I'm happy to provide as much information as I can, with the caveat that part of the source code impacted by this is not available: we're using a binary library from Nordic Semiconductor that runs code inside of a thread we're creating in our own source code.

The function being used is k_sleep(), and the function is successfully used a number of times. But, as soon as I do a particular other thing with a download client, I suddenly get the assert. Running the additional code will successfully do its stuff without issues a few times, but eventually the condition gets hit. As far as I can tell, it's not a race condition but rather based on some sort of state in the Nordic library.

 

Here's the assertion in the debug log:

ASSERTION FAIL [!z_is_thread_state_set(_kernel.current, ((1UL << (4))))] @ ZEPHYR_BASE/kernel/sched.c:1096

 

[00:05:05.932,373] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000457 r2/a3: 0x00000001

[00:05:05.941,314] <err> os: r3/a4: 0x00063757 r12/ip: 0x00000030 r14/lr: 0x00054c2b

[00:05:05.950,256] <err> os: xpsr: 0x61040000

[00:05:05.955,657] <err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001

[00:05:05.966,400] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001

[00:05:05.977,172] <err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001

[00:05:05.987,915] <err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001

[00:05:05.998,657] <err> os: fpscr: 0x00000000

[00:05:06.004,028] <err> os: Faulting instruction address (r15/pc): 0x00058806

[00:05:06.012,176] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0

[00:05:06.020,111] <err> os: Current thread: 0x200276c4 (unknown)

[00:05:06.027,099] <err> fatal_error: Resetting system

581 - 600 of 2542