Date   

Zephyr: Toolchain Working Group - Mon, 01/25/2021 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Monday, 25 January 2021
4:00pm to 5:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Zephyr: Toolchain Working Group - Mon, 01/25/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Monday, 25 January 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Torsten Rasmussen

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Zephyr 2.5.0-rc1 tagged

Nashif, Anas
 

Hi,

The first release candidate for Zephyr 2.5.0 has been tagged (v2.5.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.5.0 is released; the stabilization period is now open. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.5.0 release require approval by the TSC.

As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers. You can follow the bug numbers with the thresholds for each bug category here:

                https://testing.zephyrproject.org/issues/zephyrproject-rtos/zephyr/index.html

Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline. Everyone is encouraged, especially hardware vendors, to test on hardware available to them. Use twister to run tests from the Zephyr tree on the boards you have using the device testing features.

The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.5.0-rc1

We plan to release weekly candidates (2.5.0-rcx) leading to the final release (2.5.0) which is tentatively scheduled for 15 February.

You may continue to submit pull requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the largest extent possible, so that we can release 2.5.0 on time and in the best shape possible.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution!

Anas

 

 


Re: CANopen error message

"Karsten König <karsten.koenig.030@...>
 

Hi,

failing to register rx filters sounds like a mismatch between the number of filters that canopen expects and the ones configured for the MCP2515. Until recently these were independent KConfigs, but I removed that distinction here, especially due to the risk of running into this.
https://github.com/zephyrproject-rtos/zephyr/pull/31197

Can you check whether you have that change already in your local branch?
If yes I'd still check why it failed attaching more filters, that looks suspicious. CO_CANrxBufferInit() returns an error if there is not enough filters, yet CO_init() seems to return successfully, looks like there is also a missing check for return values, but I don't really know canopen :-(

Cheers,
Karsten

On 1/21/21 5:37 PM, Cristian Anceschi wrote:
Hi all
I'm developing a CANOPEN node based on an nRF52DK nRF52832
(PCA10040) board  wired to a MCP2515 and a MCP2551 devices.
So far, through a CAN Interface for USB plugged to a PC, I can
receive and transmit packets and command from and to the board
When I compile the project and launch the Zephyr debug, the first
message received by the PC over the CAN bus is an error message (hex
string). Received only once, at reset.
08A 00 61 01 2A 00 00 00 00 00
which means that the system it is unable to allocate memory for
object (CO_EM_MEMORY_ALLOCATION_ERROR).
The log file at the boot is
  *** Booting Zephyr OS build v2.4.0-ncs1  ***
[00:00:02.737,579] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes [0m
[00:00:02.737,579] [0m<inf> fs_nvs: alloc wra: 1, e90 [0m
[00:00:02.737,579] [0m<inf> fs_nvs: data wra: 1, 210 [0m
[00:00:02.739,776] [0m<dbg> canopen_storage.canopen_settings_set:
restored object dictionary EEPROM entries [0m
[00:00:02.739,807] [0m<dbg> canopen_driver.CO_CANmodule_init: rxSize
= 13, txSize = 9 [0m
*[00:00:02.740,814] [1;31m<err> canopen_driver: failed to attach CAN
rx isr, no free filter [0m
[00:00:02.740,875] [1;31m<err> canopen_driver: failed to attach CAN
rx isr, no free filter [0m
[00:00:02.740,905] [1;31m<err> canopen_driver: failed to attach CAN
rx isr, no free filter [0m*
[00:00:02.740,966] [0m<inf> app: CANopen stack initialized [0m
After this a guard message (hex string) , every 1 second,  is
received over the CAN bus
70A 7F
The node appears in pre-operational state.
No other error messages are shown by the PC via the Zephyr debug system.
In this condition, sending NMT commands, it is possible to force the
node to:
* Enter in STOP mode
* Enter in Pre-operational mode (from STOP mode)
* Reset node
* Reset communication
The node however doesn't enter in operational mode.
Might the reason for this latest fact be, that there is an error at
reset, so that the node won't enter in operational mode because of this?
What can be the cause of the error? Is there a THREAD STACK SIZE or
some other parameter I have to change to solve the problem?
Or can I suppose that the error message can be overlooked because
the node has to start and then everything works as expected? I mean,
the node after all IS receiving commands like I said above.
In any case I believe that the node has to be moved away from the
error condition in order to proceed. What should be the best way to
do this?                               Thanks in advance for any hints and
support Kind regards                                                         Cristian


CANopen error message

Cristian Anceschi <cristian.anceschi@...>
 

Hi all

I'm developing a CANOPEN node based on an nRF52DK nRF52832 (PCA10040) board  wired to a MCP2515 and a MCP2551 devices.
So far, through a CAN Interface for USB plugged to a PC, I can receive and transmit packets and command from and to the board

When I compile the project and launch the Zephyr debug, the first message received by the PC over the CAN bus is an error message (hex string). Received only once, at reset.

08A 00 61 01 2A 00 00 00 00 00

which means that the system it is unable to allocate memory for object (CO_EM_MEMORY_ALLOCATION_ERROR).
The log file at the boot is

  *** Booting Zephyr OS build v2.4.0-ncs1  ***
[00:00:02.737,579] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes [0m
[00:00:02.737,579] [0m<inf> fs_nvs: alloc wra: 1, e90 [0m
[00:00:02.737,579] [0m<inf> fs_nvs: data wra: 1, 210 [0m
[00:00:02.739,776] [0m<dbg> canopen_storage.canopen_settings_set: restored object dictionary EEPROM entries [0m
[00:00:02.739,807] [0m<dbg> canopen_driver.CO_CANmodule_init: rxSize = 13, txSize = 9 [0m
[00:00:02.740,814] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m
[00:00:02.740,875] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m
[00:00:02.740,905] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m

[00:00:02.740,966] [0m<inf> app: CANopen stack initialized [0m
 
After this a guard message (hex string) , every 1 second,  is received over the CAN bus

70A 7F

The node appears in pre-operational state.
No other error messages are shown by the PC via the Zephyr debug system.

In this condition, sending NMT commands, it is possible to force the node to:
  • Enter in STOP mode
  • Enter in Pre-operational mode (from STOP mode)
  • Reset node
  • Reset communication
The node however doesn't enter in operational mode.

Might the reason for this latest fact be, that there is an error at reset, so that the node won't enter in operational mode because of this?
What can be the cause of the error? Is there a THREAD STACK SIZE or some other parameter I have to change to solve the problem?

Or can I suppose that the error message can be overlooked because the node has to start and then everything works as expected? I mean, the node after all IS receiving commands like I said above.

In any case I believe that the node has to be moved away from the error condition in order to proceed. What should be the best way to do this?                                                                                                                                                                                                                                                                                                      Thanks in advance for any hints and support                                                                                                                                                                                                                                                                                                                                          Kind regards                                                                                                                Cristian                                                                                                                                                                                                                                                                                                                                                                                                                                           


Zephyr Project: Dev Meeting - Thu, 01/21/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 21 January 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Jan 21

Kumar Gala
 

Here’s the agenda topics for this week:

* west: build: [RFC] Generate SPDX tag-value documents
- https://github.com/zephyrproject-rtos/zephyr/pull/31065


* WIP: Move power subsystem to new power states
- https://github.com/zephyrproject-rtos/zephyr/pull/31273
* Mapping between existing and new system power management states
- https://github.com/zephyrproject-rtos/zephyr/issues/31162


(If any updates)
* linker: generate memory regions from devicetree partitions
https://github.com/zephyrproject-rtos/zephyr/pull/31077
* Zephyr: re-work DT flash partitioning for Nordic nRF boards in the tree
https://github.com/zephyrproject-rtos/zephyr/pull/29794



* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Re: West and git reference repositories

Carles Cufi
 

Hi Michael,

 

You can use the clone-depth attribute in projects, but there’s an ongoing effort for shallow cloning that we plan to revisit very soon:

https://github.com/zephyrproject-rtos/west/issues/319

 

Carles

 

From: devel@... <devel@...> On Behalf Of michael.rosenblum via lists.zephyrproject.org
Sent: 20 January 2021 22:03
To: devel@...
Subject: [Zephyr-devel] West and git reference repositories

 

Hi All,

I have been trying to find any info about using a git reference repos to speed up the clones with west, but I can't seem to find any documentation that mentions it.
Is there some config that I missed?

Mike 


West and git reference repositories

michael.rosenblum@...
 

Hi All,

I have been trying to find any info about using a git reference repos to speed up the clones with west, but I can't seem to find any documentation that mentions it.
Is there some config that I missed?

Mike 


Zephyr Project: APIs - Tue, 01/19/2021 5:00pm-6:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 19 January 2021, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr Project: Dev Meeting - Thu, 01/14/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 14 January 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zero latency interrupt extension for ARMv6-M

Fabio Egg <fegg@...>
 

Hi all,

 

I would like to extend the zero latency interrupt feature to processors with an ARMv6-M architecture such as ARM Cortex M0, M0+ and M1. Is somebody already working on such a feature extension or has some ideas concerning this?

In the following I present a rough concept, how I would implement it. I am open to suggestions.

 

Initial position

The concerning processors have two possibilities to disable exceptions with configurable priorities. First, the Priority Mask core register (PRIMASK), which prevents the activation of all exceptions with configurable priority. Secondly, the Interrupt Clear-Enable register (CLRENA) of the Nested Vector Interrupt Controller that can disable each of the 32 interrupts individually. The PRIMASK is currently used for the IRQ lock of these processors.

 

Suggested solution

To implement a zero latency interrupt on ARMv6-M architecture the locking function has to be complemented by an additional compiler directive (#ifdef). The locking of the interrupts first saves the value of the NVIC_ICER into a shadow register and then clears all interrupts except of the interrupts registered as zero latency interrupt. For the functions that access the NVIC_ICER and NVIC_ISER register, a guard has to be implemented. This guard shall update the shadow register instead of writing to the NVIC_ICER and NVIC_ISER register. To unlock the interrupts, this shadow register will be written to NVIC_ISER and enable the interrupts again.

 

Additional notes

The feature that the IRQ lock is thread specific should not be restricted, since the changes mainly happen in the arch_irq_lock function.

There have to be some rules to prevent an inconsistency with the IRQ priority. The zero latency IRQ has to be registered with the highest interrupt priority available. If multiple zero latency interrupts are registered, they have to be on the same priority. With multiple zero latency IRQ, the zero latency can only be guaranteed, if they are strictly sequential.

 

Regards,

Fabio Egg

 


Dev-Review Meeting Agenda Jan 14

Kumar Gala
 

Here’s the agenda topics for this week:

* auth: new authentication library
- https://github.com/zephyrproject-rtos/zephyr/pull/31136

* linker: generate memory regions from devicetree partitions #31077
- https://github.com/zephyrproject-rtos/zephyr/pull/31077

* kernel.threads.tls.userspace fails with SDK 0.12.0-beta on ARM Cortex-M
- https://github.com/zephyrproject-rtos/zephyr/issues/30393

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


v2.5.0 merge window closes Friday, January 22nd

Nashif, Anas
 

Hi,

This is a reminder that the v2.5.0 merge window for new features closes this Friday, 22nd January. After that, only bug fixes and documentation will be merged until the final release is tagged, which is targeted for Friday, February 12th. Exceptions require TSC approval. New feature PRs may still be submitted while the merge window is closed, but please keep in mind that maintainers will have less time to review them during the release stabilization period.

Please add the v2.5.0 milestone to PRs that need to be included in the release, and do not wait until Friday, January 22nd to submit them.

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+milestone%3Av2.5.0

Please try to help fix bugs, test release candidates, and write release notes to minimize the time the merge window is closed so we can all quickly get back to adding fun new things to Zephyr! 

Thank you for your contributions!

Regards,

Anas Nashif


Zephyr Project: APIs - Tue, 01/12/2021 5:00pm-6:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 12 January 2021, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr: Toolchain Working Group - Mon, 01/11/2021 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Monday, 11 January 2021
4:00pm to 5:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Zephyr: Toolchain Working Group - Mon, 01/11/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Monday, 11 January 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Torsten Rasmussen

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


MAINTAINERS file and Pull-Request assignments

Nashif, Anas
 

Hi,

 

Based on various discussions and decisions made last year we introduced the MAINTAINERS file which serves as main place for documenting areas of the Zephyr code base and the respective maintainers and collaborators of those areas.

The goal has been to identify all key areas and the maintainers of those areas and use robots (CI) to add reviewers and labels and add assignees for each pull request submitted to the Zephyr project to accelerate reviews and bring pull requests to a mergable state. Assignees in the context will be responsible for driving a pull request to a mergeable state. (for example, getting the required 2 approvals, helping contributors with the code changes, deal with stale reviews, etc.)

 

For more information, see https://docs.zephyrproject.org/latest/contribute/project_roles.html?highlight=maintainers#teams-and-supporting-activities

 

Some of you have noticed over the last week pull-requests being assigned to you by *zephyr-bot*. This was a first attempt to deal with all open pull-requests and set the right assignee and add reviewers based on the data in the MAINTAINERS file. This activity was done manually using a script.

 

The plan is to integrate this as a Github action and set assignee and add reviewers for new pull requests, something that will happen by the end of this week.

 

Please help us improve this process and the data in the MAINTAINERS file:

  • Review the PRs that were assigned to you and let us know if you think something was incorrectly assigned to you.
  • Review the MAINTAINERS file and examine the areas you are responsible for and add any missing paths
  • Review PRs where you were added as reviewers and report any issues

 

We are already aware of some issues with adding reviewers where already existing reviewer were added or removed by mistake. This was fixed already in the script.

 

The baseline for the assignments was this PR https://github.com/zephyrproject-rtos/zephyr/pull/31101. This PR already has some significant changes, and it should be merged soon.

 

Use slack or reply to this email if you have any questions or concerns.

 

Regards,

Anas Nashif

 

501 - 520 of 8040