Date   
Re: MCUMGR - sends responses to wrong port

Carles Cufi
 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

GH auto-close policy

Boie, Andrew P
 

Hi All,

 

I think we need to re-examine the current policy of auto-closing bugs after 60 days of no activity. I understand the intent, we don't want stale bugs lying around, but I think what we have now introduces some bad incentives.

 

The current policy that was recently introduced is, AFAICT:

  • If a bug is idle for 60 days, a warning is posted to the GH ticket
  • If the warning is not responded to within 14 days, the bug is closed.

 

This unfortunately creates an incentive for bug assignees to simply ignore bugs that are assigned to them, as after a while they will go away.

The onus is currently on the *reporter* to keep these bugs from auto-closing. Because it's the reporter who cared enough to open the bug report to begin with. The assignee may not care at all, or have bigger fish to fry.

 

I will freely admit to ignoring some P3 bugs assigned to me by the Coverity-Bot, I'd probably get around to them eventually if someone started bugging me about them, but as it stands now they just got auto-closed a few days ago and now I probably don't have to worry about them ever!

I know that I've filed several P3 issues against x86_64 that I assigned to myself that I don't plan on getting around to for a while, but I would very much not like to lose the information that these bugs exist at all!

 

As it stands now, as someone who opens a lot of bugs, of varying priority levels, I have to either:

  • Monitor all my GitHub emails, every day, for warnings that some bug I opened that the assignee ignored is about to be auto-closed. I get hundreds to over a thousand GitHub emails every day.
  • On a bi-weekly basis, review every single bug I've opened to check for warnings from github-actions and prod them so they don't get auto-closed. I currently have 27 bugs open that I reported. I don't know how many have been auto-closed already.

 

Maybe this was all anticipated and that's how we want it. But if not I think the current policy needs to be thought about some more, and while that's taking place I ask that this mechanism be disabled.

 

Andrew

MCUMGR - sends responses to wrong port

Lawrence King
 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

Re: QEMU networking problem - has anyone ever run into this problem?

Jett ✈ Rink
 

Can you post what you figured out for posterity sake in case anyone else runs into the same issue?


On Tue, Jul 14, 2020 at 6:55 AM Immo Birnbaum <immo.birnbaum@...> wrote:
Nevermind, I figured it out...

RFC: subsys: fs: Support file open flags to fs and POSIX API

Ermel, Dominik
 

Hi,

 

There is proposal for change to fs_open, within Zephyr FS API. You are invited to post your comments here https://github.com/zephyrproject-rtos/zephyr/issues/26833 .

 

Thanks in advance and best regards,

Dominik Ermel

 

Dominik ERMEL | Senior Software Engineer
M +48 505 071 130 | Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

Zephyr Project: APIs - Tue, 07/14/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 14 July 2020, 4:00pm to 5: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
 
 
________________________________________________________________________________

app external lib use zephyr driver fail

FrankLi
 

Hi guys,
I refer to external_lib sample create a app external lib , in external lib source code include "driver/display.h".
during build, show below error message, It seems that extern lib is generated before syscall, which will cause dependency problems. Is there a way to adjust extern lib to syscall and compile it?
My code base is v2.2.0
In file included from /mnt/e/westz/zephyrproject/zephyr/include/kernel_includes.h:32,
                 from /mnt/e/westz/zephyrproject/zephyr/include/kernel.h:17,
                 from /mnt/e/westz/zephyrproject/zephyr/include/device.h:10,
                 from /mnt/e/westz/zephyrproject/zephyr/include/drivers/display.h:22,
                 from src/SwiftDisplay.c:1:
/mnt/e/westz/zephyrproject/zephyr/include/syscall.h:11:10: fatal error: syscall_list.h: No such file or directory
   11 | #include <syscall_list.h>

Re: QEMU networking problem - has anyone ever run into this problem?

Immo Birnbaum
 

Nevermind, I figured it out...

API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow's topics:

- Conclusion on fs_open() flags Stable API Change:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/26833

- RFC: Require system clock stability on startup
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22758

- hwinfo reset cause support
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24884

- drivers: ethernet: unify the initialization (if stakeholders present)
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21452

- Go through issues in the In Progress column to clean them up

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.

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

RFC: API Change: watchdog: wdt_feed error codes

Peter A. Bigot
 

The API change proposed here and summarized below has been completed.

Following https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html#stable we have a need to make a small change to the watchdog API that meets the criteria of "...forces users to modify their existing code in order to maintain the current behavior of their application".

Please see: https://github.com/zephyrproject-rtos/zephyr/issues/26708

Peter

QEMU networking problem - has anyone ever run into this problem?

Immo Birnbaum
 

Hi all,

I'm having a bit of an issue when it comes to exchanging network packets with QEMU via the TAP interface "zeth" as set up by net-setup.sh.

When building the TCP socket echo server demo for the qemu_x86 target with the e1000 driver enabled within Zephyr and -nic tap,model=e1000 passed to QEMU (Ethernet mode, SLIP driver disabled), the TAP interface works as expected while QEMU is running. When building the same application for the qemu_cortex_r5 target (which simulates the UltraScale RPU on the Xilinx ZCU102 board) using my Xilinx GEM network driver, in this case the QEMU networking parameter is -nic tap,model=cadence_gem, there's an odd effect I can't really make any sense of. When I ping the IP address used by Zephyr, an ARP request is sent, an ARP reply is received, "arp -i zeth" on the host side shows the correct MAC/IP tuple. These packets show up in Wireshark which is running at the same time acquiring all traffic on the zeth interface.

Afterwards, the ICMP echo request is sent by the Linux host, Zephyr receives it and generates a reply (visible both as hexdump on the Zephyr console and within Wireshark). As more requests and replies are sent, the seq number in the ICMP packets increases, each reply packet's seq matches that of the previous request. Yet, the ping command on the Linux host doesn't receive this data. The output generated by ping is always "x packets transmitted, 0 received, 100% loss". Yet, when calling ifconfig, a non-zero packet count is shown for both RX and TX, and those numbers match the packets logged by Wireshark. Ifconfig also shows that for both RX and TX, there were no errors, no overruns, no packets dropped and no collisions. The same phenomenon can be observed when trying to connect to the port opened by the echo server using PUTTY: the SYN packet is sent by the host, Zephyr generates the SYN/ACK reply, again visible in Wireshark, the calling application doesn't receive the data and sends another SYN packet multiple times, to which Zephyr replies with RST/ACK each time. PUTTY eventually indicates a timeout.

I'm at a loss as to why all packets are visible within Wireshark, so therefore, the zeth interface seems to work as expected, but the data in the Zephyr->host direction isn't handed over to the calling application, which works fine on the x86 target. I eventually suspected a bug within QEMU itself and built the latest version (both from the main repo and the Xilinx branch) from source, unfortunately, this didn't solve the problem. Has anyone ever observed this problem before when running a networking-enabled Zephyr application within QEMU?

Max Possible BLE communication range with Zephyr's 'hci_uart' app on nrf52840 chip #hci #nrf52480 #uart #ble #bluetooth

Mayank
 

Hello Community,
 
We are using nordic's nrf52840_pca10056 chip on our custom board and on top of that zephyr's 'hci_uart' application is running. (Zephyr version v2.1.0).On our custom board, the host side(i.MX6ull) we are using Linux kernel (v4.19) and integrated Bluez's stack (v5.50) with it.
 
Zephyr's application gives access to the 'hci0' interface at the host side and We are able to scan nearby BLE device and beacon using BLUEZ test utility. Currently, we are performing the connection stability test with different range and for that we are trying to make a connection to BLE devices, Let's say connecting to the Nordic's nrf52840 dev kit which is flashed with Zephyr's Peripheral application(peripheral_csc). In this case, we just getting 18 meters line of sight (indoor environment), Connection starts dropping as soon as we put the wooden door obstacles in the path.
 
In this case, We have a concern regarding the 'Max Range' till which our custom board's nrf52840 chip would be able to maintain the connection with the dev kit.
 
Please note: We have flashed Beacon application on our custom board having "nrf52840_pca10056" chip and it was visible more than 100 meters of range. But with connectable devices, our custom board is not able to communicate the BLE device which is available more than 18 meters range.
 
Q1: How could we increase the connection range with a more stable connection?
Zephyr Configurations:
In Zephyr's 'hci_uart' application, 
1) We have changed 'Tx power' parameter to 8 dbm (Highest).
2) Enabled 'Coded PHY' along with the '2Mbps PHY' to increase the BLE range.3) We are using the RC oscillator crystal with "CLOCK_CONTROL_NRF_K32SRC_20PPM" option.
 
Q2: Are there any more parameters that we can enable from zephyr, which could help in increasing the long-range BLE communication?
Q3: As of now, We are using Bluez stack's & Linux kernel's default parameters, Is there any BLE connection parameters which could help in increasing the long-range BLE communication?

Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI

Marcio Montenegro
 

Olá,

Eu acabei de assinar o abaixo-assinado "Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI" e queria saber se você pode ajudar assinando também.

A nossa meta é conseguir 200.000 assinaturas e precisamos de mais apoio. Você pode ler mais sobre este assunto e assinar o abaixo-assinado aqui:

http://chng.it/zVM9JvLdfC

Obrigada/Obrigado!
Marcio

Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI

Marcio Montenegro
 

Olá,

Eu acabei de assinar o abaixo-assinado "Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI" e queria saber se você pode ajudar assinando também.

A nossa meta é conseguir 200.000 assinaturas e precisamos de mais apoio. Você pode ler mais sobre este assunto e assinar o abaixo-assinado aqui:

http://chng.it/zVM9JvLdfC

Obrigada/Obrigado!
Marcio

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 07/09/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 9 July 2020, 3:00pm to 4: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
 
 
________________________________________________________________________________

Re: Dev-Review Meeting Agenda Jul 9

Peter A. Bigot
 

Two items for dev-review:
* https://github.com/zephyrproject-rtos/zephyr/pull/26025#issuecomment-656044858 against https://github.com/zephyrproject-rtos/zephyr/pull/26750#discussion_r452120857 and the question of whether optional API should be declared or not relative to use of `if (IS_ENABLED())`.  This may also be appropriate for API.
* https://github.com/zephyrproject-rtos/zephyr/pull/24794#pullrequestreview-444964843
 

Zephyr: Toolchain Working Group - Thu, 07/09/2020 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Thursday, 9 July 2020
2:00pm to 3: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
 
 
________________________________________________________________________________

Upcoming Event: Zephyr: Toolchain Working Group - Thu, 07/09/2020 2:00pm-3:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Thursday, 9 July 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Maureen Helm

Description:

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

Dev-Review Meeting Agenda Jul 9

Kumar Gala
 

Here’s the agenda topics for this week:

* Any PR/issues w/dev-review tag

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

* Any topics anyone else has.

- k

Zephyr Toolchain Working Group Meeting – 09 July 2020

Rasmussen, Torsten
 

Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 682 738 030#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

 

________________________________________________________________________________

 

 

 

Torsten Tejlmand Rasmussen

Senior R&D Engineer

P: +47 72 89 92 47

 

Nordic

 

Nordic Semiconductor

Otto Nielsens veg 12, 7052 Trondheim, Norway

www.nordicsemi.com

 

 

SM_symbol_FB  nordic_symbol_small_TW  nordic_symbol_small_YT_ny2  nordic_symbol_small_IN  

 

DevZone