Date   

Re: Bluez' mesh-cfgclient fails to retrieve composition data from onoff-app sample

Trond Snekvik
 

Hi, 

Looks like this is caused by a discrepancy between what MIC length was passed into the encryption function and packet assembly when the MIC length is 8 (which just happens in segmented messages).


Please test it and provide feedback if you can.

Thanks for the detailed bug report!

Trond


From: Steve Brown <sbrown@...>
Sent: Monday, November 2, 2020 18:13
To: zephyr-devel@... <zephyr-devel@...>
Cc: Snekvik, Trond <Trond.Einar.Snekvik@...>
Subject: Bluez' mesh-cfgclient fails to retrieve composition data from onoff-app sample
 
I bisected this to eca014115 
Bluetooth: Mesh: Isolate cryptographic material

I suspect segmented messages. The successful sequence number starts at
2 whereas the failing one starts at 1.

I'm not familiar enough with the code to go further than this.

Nothing appears in the meshd debug log with the failing case.

Provisioning succeeds and configuration commands that return
unsegmented messages, like ttl-get, work.

Steve

FAILING TRACE
[00:00:44.745,727] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:44.745,758] <dbg> bt_mesh_access.model_send: len 50: 0200f105000000000a0003000000050~
[00:00:44.745,788] <dbg> bt_mesh_transport.bt_mesh_trans_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:44.745,819] <dbg> bt_mesh_transport.bt_mesh_trans_send: len 50: 0200f105000000000a0003000000050~
[00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: src 0x0116 dst 0x0001 app_idx 0xfffe aszmic 1 sdu_len 54
[00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0001 (segs: 5)
[00:00:44.746,002] <dbg> bt_mesh_transport.send_seg: seg 0: 581b6de7e895153634729e5a
[00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 1: 78298189c7f317ef0d1bf4c0
[00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 2: 3def2b3f3ff14af374b4cda1
[00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 3: ce9fa72cb97cf05f4986433d
[00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 4: b4e6c4dc7c54
[00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked: SeqZero: 0x0001 Attempts: 4
[00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 0/4
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800404581b6de7e895153634729e5~
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000001
[00:00:44.746,154] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000001
[00:00:44.746,307] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 1/4
[00:00:44.746,307] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 8080042478298189c7f317ef0d1bf4c~
[00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
[00:00:44.746,337] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000002
[00:00:44.746,490] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 2/4
[00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808004443def2b3f3ff14af374b4cda~
[00:00:44.746,551] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
[00:00:44.746,551] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000003
[00:00:44.746,704] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 3/4
[00:00:44.746,704] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800464ce9fa72cb97cf05f4986433~
[00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
[00:00:44.746,765] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000004
[00:00:44.746,917] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 4/4
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 10 headroom 9 tailroom 10
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 10: <log_strdup alloc failed>
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
[00:00:44.746,948] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000005

SUCCESS
[00:00:50.364,929] <dbg> bt_mesh_cfg_srv.dev_comp_data_get: net_idx 0x0000 app_idx 0xfffe src 0x0001 len 1: 00
[00:00:50.364,959] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:50.364,990] <dbg> bt_mesh_access.model_send: len 50: 0200f105000000000a0003000000050~
[00:00:50.364,990] <dbg> bt_mesh_transport.bt_mesh_trans_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:50.365,051] <dbg> bt_mesh_transport.bt_mesh_trans_send: len 50: 0200f105000000000a0003000000050~
[00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: src 0x011a dst 0x0001 app_idx 0xfffe aszmic 1 sdu_len 58
[00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0002 (segs: 5)
[00:00:50.365,234] <dbg> bt_mesh_transport.send_seg: seg 0: 0c0139ab229a128ab4d9da66
[00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 1: 7911abbd986ab5cc2ba3a7fd
[00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 2: b9460beeec1aca3c73012043
[00:00:50.365,295] <dbg> bt_mesh_transport.send_seg: seg 3: 254d22b179271b62687efbed
[00:00:50.365,325] <dbg> bt_mesh_transport.send_seg: seg 4: 6c7b29d675eb290476cd
[00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked: SeqZero: 0x0002 Attempts: 4
[00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 0/4
[00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808008040c0139ab229a128ab4d9da6~
[00:00:50.365,386] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
[00:00:50.365,386] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000002
[00:00:50.365,539] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 1/4
[00:00:50.365,539] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808008247911abbd986ab5cc2ba3a7f~
[00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
[00:00:50.365,600] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000003
[00:00:50.365,722] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 2/4
[00:00:50.365,753] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800844b9460beeec1aca3c7301204~
[00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
[00:00:50.365,783] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000004
[00:00:50.365,936] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 3/4
[00:00:50.365,936] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: <log_strdup alloc failed>
[00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
[00:00:50.365,966] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000005
[00:00:50.366,119] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 4/4
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 14 headroom 9 tailroom 6
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 14: <log_strdup alloc failed>
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000006
[00:00:50.366,149] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000006



Bluez' mesh-cfgclient fails to retrieve composition data from onoff-app sample

Steve Brown
 

I bisected this to eca014115 
Bluetooth: Mesh: Isolate cryptographic material

I suspect segmented messages. The successful sequence number starts at
2 whereas the failing one starts at 1.

I'm not familiar enough with the code to go further than this.

Nothing appears in the meshd debug log with the failing case.

Provisioning succeeds and configuration commands that return
unsegmented messages, like ttl-get, work.

Steve

FAILING TRACE
[00:00:44.745,727] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:44.745,758] <dbg> bt_mesh_access.model_send: len 50: 0200f105000000000a0003000000050~
[00:00:44.745,788] <dbg> bt_mesh_transport.bt_mesh_trans_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:44.745,819] <dbg> bt_mesh_transport.bt_mesh_trans_send: len 50: 0200f105000000000a0003000000050~
[00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: src 0x0116 dst 0x0001 app_idx 0xfffe aszmic 1 sdu_len 54
[00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0001 (segs: 5)
[00:00:44.746,002] <dbg> bt_mesh_transport.send_seg: seg 0: 581b6de7e895153634729e5a
[00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 1: 78298189c7f317ef0d1bf4c0
[00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 2: 3def2b3f3ff14af374b4cda1
[00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 3: ce9fa72cb97cf05f4986433d
[00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 4: b4e6c4dc7c54
[00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked: SeqZero: 0x0001 Attempts: 4
[00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 0/4
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800404581b6de7e895153634729e5~
[00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000001
[00:00:44.746,154] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000001
[00:00:44.746,307] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 1/4
[00:00:44.746,307] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 8080042478298189c7f317ef0d1bf4c~
[00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
[00:00:44.746,337] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000002
[00:00:44.746,490] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 2/4
[00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808004443def2b3f3ff14af374b4cda~
[00:00:44.746,551] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
[00:00:44.746,551] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000003
[00:00:44.746,704] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 3/4
[00:00:44.746,704] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800464ce9fa72cb97cf05f4986433~
[00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
[00:00:44.746,765] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000004
[00:00:44.746,917] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 4/4
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst 0x0001 len 10 headroom 9 tailroom 10
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 10: <log_strdup alloc failed>
[00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
[00:00:44.746,948] <dbg> bt_mesh_net.net_header_encode: src 0x0116 dst 0x0001 ctl 0 seq 0x000005

SUCCESS
[00:00:50.364,929] <dbg> bt_mesh_cfg_srv.dev_comp_data_get: net_idx 0x0000 app_idx 0xfffe src 0x0001 len 1: 00
[00:00:50.364,959] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:50.364,990] <dbg> bt_mesh_access.model_send: len 50: 0200f105000000000a0003000000050~
[00:00:50.364,990] <dbg> bt_mesh_transport.bt_mesh_trans_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:50.365,051] <dbg> bt_mesh_transport.bt_mesh_trans_send: len 50: 0200f105000000000a0003000000050~
[00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: src 0x011a dst 0x0001 app_idx 0xfffe aszmic 1 sdu_len 58
[00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0002 (segs: 5)
[00:00:50.365,234] <dbg> bt_mesh_transport.send_seg: seg 0: 0c0139ab229a128ab4d9da66
[00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 1: 7911abbd986ab5cc2ba3a7fd
[00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 2: b9460beeec1aca3c73012043
[00:00:50.365,295] <dbg> bt_mesh_transport.send_seg: seg 3: 254d22b179271b62687efbed
[00:00:50.365,325] <dbg> bt_mesh_transport.send_seg: seg 4: 6c7b29d675eb290476cd
[00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked: SeqZero: 0x0002 Attempts: 4
[00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 0/4
[00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808008040c0139ab229a128ab4d9da6~
[00:00:50.365,386] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
[00:00:50.365,386] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000002
[00:00:50.365,539] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 1/4
[00:00:50.365,539] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 808008247911abbd986ab5cc2ba3a7f~
[00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
[00:00:50.365,600] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000003
[00:00:50.365,722] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 2/4
[00:00:50.365,753] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80800844b9460beeec1aca3c7301204~
[00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
[00:00:50.365,783] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000004
[00:00:50.365,936] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 3/4
[00:00:50.365,936] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 16 headroom 9 tailroom 4
[00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: <log_strdup alloc failed>
[00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
[00:00:50.365,966] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000005
[00:00:50.366,119] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 4/4
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst 0x0001 len 14 headroom 9 tailroom 6
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 14: <log_strdup alloc failed>
[00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000006
[00:00:50.366,149] <dbg> bt_mesh_net.net_header_encode: src 0x011a dst 0x0001 ctl 0 seq 0x000006


API meeting: agenda

Carles Cufi
 

Hi all,

Agenda for tomorrow.

Note: the API and component naming conventions (https://github.com/zephyrproject-rtos/zephyr/issues/29569) discussion has been postponed until next week since tomorrow the availability of US-based engineers is restricted.

- devicetree-based device definitions and dependency representations
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/29644

- Reminder and questions about: API to correlate system time with external time sources and translate uptime to wall-clock time
- PR https://github.com/zephyrproject-rtos/zephyr/pull/28977

- Introduction of a new work queue
- PR https://github.com/zephyrproject-rtos/zephyr/pull/29618

and then, time permitting we'd like to follow-up on pinctrl:

- Pinmux and pinctrl API: Decide what the priorities for this are, and how to get to LTS with it
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748

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

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Zephyr Toolchain Working Group Meeting – 2 November 2020

Rasmussen, Torsten
 

Today’s MoM:

 

Notes/Minutes

  • LLVM
    • #24917, infrastructure in place and works, when linking with GNU ld.
      • Work needed regarding:
        • Linking with llvm-ld (log2ceil)
        • Linking with llvm-ldd
        • Compiler-rt
  • Zephyr SDK
    • Beta Zephyr SDK 0.12 last week
    • Outstanding issue on Zephyr side, arm64, #28650
    • ARC / TLS support ?
      • On ARC the build itself doesn’t seem to enable it.
    • Eugeniy will look into this.
    • Cleanup and add Kconfig regarding TLS support, default to `n`
      Also allow users to specify if he know the toolchain support TLS
      • Newlib should be part of this cleanup   
      • Are we mixing Kconfig too much with toolchain properties ?
      • Having information in both places, having CMake drives the Kconfig values ?
    • Nothing happening on new packaging regarding Windows / macOS platform
      • No further work is expected to happen regarding Zephyr SDK for Windows / MacOS, unless someone has the time and volunteers to drive this forward.
        It’s better to focus resources on better toolchain support, such as LLVM.

 

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

 

Thanks to all participants for good discussions.

 

/torsten

 

From: Rasmussen, Torsten
Sent: 2 November, 2020 14:37
To: devel@...
Subject: Zephyr Toolchain Working Group Meeting – 2 November 2020

 

Call for today’s Toolchain WG.

 

Agenda

 

·         Updates:

o    Thomas: IAR: Updates ?

o    Zephyr SDK.

§  LLVM support

§  compiler-rt.

o    #24917

§  Linking with lld.

§  Compiler-rt ?

o    Milestones for 2.5, news.

 

 

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

 

           

 


Network forum agenda

Jukka Rissanen
 


Re: #LWM2M #Leshan #FirmwareUpdate #lwm2m #leshan #firmwareupdate

Lubos, Robert
 

Hi Thomas,

 

I’m not sure if the firmware update is even achievable on qemu_x86 platform (same goes with reboot). The lwm2m_client sample does not implement the actual FW update procedure, just provide stubs to get the communication going.

 

I’ve included some more replies inline below.

 

Regards,

Robert

 

From: devel@... <devel@...> On Behalf Of Thomas LE ROUX via lists.zephyrproject.org
Sent: poniedziałek, 2 listopada 2020 17:14
To: devel@...
Subject: [Zephyr-devel] #LWM2M #Leshan #FirmwareUpdate

 

Hi everybody !

I'm trying to build a projet using Zephyr & LWM2M (& Leshan).

TL;DR before I start explaining more precisely my issue :

Having issue making a Firmware Update on a QEMU_x86 instance.

Has anyone been able to successfully achieve a Firmware Upgrade ? How ?

 

For now, I'm prototyping through QEMU.

I have made my small application to test things out, creating objects and ressources ; defining new .xml files … There's one last thing that I need to succeed before going deeper into my project : Firmware Update. I am unable to make a firmware update on my QEMU instance.

I am actually using a Leshan localhost as my LWM2M server.

I’ve tried several things :

  • Pushing using 5/0/0 :
    • File above 200ko can’t be pushed without an issue occuring (packets stop downloading and 5/0/3 remain at the value 1 (meaning « downloading ») afterwards.

Try increasing the “Response Timeout” parameter in the Leshan web UI. The Leshan will cease to transmit further updates if it does not finish the operation before “Response timeout”.

    • The .elf generated for samples/basic/hello_world is around 400ko which causes an issue here.
    • The .bin generated, however, weight around 100ko which is fine.
      • The file uploads (result can be seen on my terminal).
        • [00:00:28.040,000] <inf> net_lwm2m_client_app: FIRMWARE: BLOCK RECEIVED: len:37 last_block:1
      • The 5/0/3 State value goes to 2 (« downloaded »).
      • When I execute 5/0/2 (Update) : 5/0/5 (Update Result) goes to 1 (meaning Firmware updated successfully).
      • However, nothing happens, and my QEMU continue to respond to requests, no flash occurs.

Nothing else can be expected from the sample at this point (as I said I’m not sure if it’s possible to do the actual firmware update of the qemu_x86 image). From the LwM2M point of view, the FW update procedure is complete as the entire image was delivered to the device. You can check how does it work with an actual device for instance here:
https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/lwm2m_client/src/lwm2m/lwm2m_firmware.c

  • Pulling using 5/0/1 :
    • I've run a local server in order to make a firmware update through 5/0/1 by giving the http address of .bin and .elf.
    • When I try to Update (for .elf or .bin, i have the following Update Result : 9 (meaning « Unsupported protocol » )

This is happening because http is not implemented as a FW delivery method in the LwM2M library. For now, only CoAP block transfer is supported.

The problem might be related to the fact that some functions are not yet implemented in Zephyr (e.g : Device reboot on 3/0/4 leads to a callback doing « /* Change the battery voltage for testing */ » and no reboot, same for Factory Default ) …

My problem is pretty much described, if needed, I can send some logs.

 

Thank you for your help !

Best regards,

Thomas

 


#LWM2M #Leshan #FirmwareUpdate #lwm2m #leshan #firmwareupdate

Thomas LE ROUX
 

Hi everybody !

I'm trying to build a projet using Zephyr & LWM2M (& Leshan).

TL;DR before I start explaining more precisely my issue :

Having issue making a Firmware Update on a QEMU_x86 instance.

Has anyone been able to successfully achieve a Firmware Upgrade ? How ?


For now, I'm prototyping through QEMU.

I have made my small application to test things out, creating objects and ressources ; defining new .xml files … There's one last thing that I need to succeed before going deeper into my project : Firmware Update. I am unable to make a firmware update on my QEMU instance.

I am actually using a Leshan localhost as my LWM2M server.

I’ve tried several things :

  • Pushing using 5/0/0 :

    • File above 200ko can’t be pushed without an issue occuring (packets stop downloading and 5/0/3 remain at the value 1 (meaning « downloading ») afterwards.

    • The .elf generated for samples/basic/hello_world is around 400ko which causes an issue here.

    • The .bin generated, however, weight around 100ko which is fine.

      • The file uploads (result can be seen on my terminal).

        • [00:00:28.040,000] <inf> net_lwm2m_client_app: FIRMWARE: BLOCK RECEIVED: len:37 last_block:1

      • The 5/0/3 State value goes to 2 (« downloaded »).

      • When I execute 5/0/2 (Update) : 5/0/5 (Update Result) goes to 1 (meaning Firmware updated successfully).

      • However, nothing happens, and my QEMU continue to respond to requests, no flash occurs.

  • Pulling using 5/0/1 :

    • I've run a local server in order to make a firmware update through 5/0/1 by giving the http address of .bin and .elf.

    • When I try to Update (for .elf or .bin, i have the following Update Result : 9 (meaning « Unsupported protocol » )

The problem might be related to the fact that some functions are not yet implemented in Zephyr (e.g : Device reboot on 3/0/4 leads to a callback doing « /* Change the battery voltage for testing */ » and no reboot, same for Factory Default ) …

My problem is pretty much described, if needed, I can send some logs.


Thank you for your help !

Best regards,

Thomas



Zephyr: Toolchain Working Group - Mon, 11/02/2020 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Monday, 2 November 2020
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, 11/02/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Monday, 2 November 2020, 4:00pm to 5: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
 
 
________________________________________________________________________________


Zephyr Toolchain Working Group Meeting – 2 November 2020

Rasmussen, Torsten
 

Call for today’s Toolchain WG.

 

Agenda

 

  • Updates:
    • Thomas: IAR: Updates ?
    • Zephyr SDK.
      • LLVM support
        • compiler-rt.
    • #24917
      • Linking with lld.
      • Compiler-rt ?
    • Milestones for 2.5, news.

 

 

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

 

           

 


#uart #uart

yuta.uenishi@...
 

Hello,

I am using the stm32l152re,
I am using the mdm_receiver driver to use uart in my project.
I want to use a pointer to a callback function in my project to do a k_work_submit in a UART callback.
Is there a driver that meets my requirements?

Thanks,

Yuta


Re: Updated Event: Zephyr: Networking Forum #cal-invite

Jukka Rissanen
 

Hi all,

Tuesday (3 Nov) there is a networking forum Teams meeting. Let me know
if there are any network related topic you would like to discuss there
so I can add it to the agenda.


Cheers,
Jukka


Updated Event: Zephyr Project: Dev Meeting #cal-invite

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

Zephyr Project: Dev Meeting

When:
Thursday, 5 November 2020
4:00pm to 5:00pm
(UTC+00:00) UTC
Repeats: Weekly on Thursday

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

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


Zephyr Project: Dev Meeting - Thu, 10/29/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 29 October 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
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Oct 28

Kumar Gala
 

Here’s the agenda topics for this week:

* samples: drivers: adc: add demo and fix STM32 sequence configuration:
- https://github.com/zephyrproject-rtos/zephyr/pull/25590

* Any PR/issues w/dev-review tag

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

* Any topics anyone else has.

- k


Re: [Zephyr-users] Adding an out of tree driver

Bolivar, Marti
 

Hi,

You should just need to add it to the build system's Kconfig and
CMakeLists.txt hierarchy like any other file in your module.

There are worked examples in
https://github.com/nrfconnect/sdk-nrf/tree/master/drivers.

HTH,
Martí

"Lawrence King via lists.zephyrproject.org"
<lawrence.king=irdeto.com@lists.zephyrproject.org> writes:

Adding an out of tree board is easy, I just set the variable BOARD_ROOT and the build system happily finds my_custom_board. This is nicely described by following the links from here: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Fapplication%2Findex.html%23boards&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659844236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=HLSJWOCIo1bmNd7toN8PiWy4yPKgDoKUSgwu4dc6HMY%3D&amp;reserved=0

Now I want to do the same for my_custom_sensor_driver. Is there a variable I can set (like SENSOR_ROOT) that will find my out of tree sensor driver? Unfortunately the documentation at https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2F2.3.0%2Fsamples%2Fapplication_development%2Fout_of_tree_driver%2FREADME.html&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4qznVND3NnjhnL6oS0evZVz89Uqi0Tk4zIpPycsMX3I%3D&amp;reserved=0 is a little sparse.

How do I include an out of tree sensor driver?

Lawrence King
Principal Developer
Connected Transport Market Unit
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irdeto.com%2F&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=DuktziXbXA7dDl%2BDxoD5cMHtFNUn0EtQfEKdmMK9SDI%3D&amp;reserved=0
+1(416)627-7302

[1]<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcareers.irdeto.com%2F&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Z8rh2RzZbwZp0PtsYk8Asrn2CALvLKN6B7SRKWNDR3g%3D&amp;reserved=0> [2 - linkedin] <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Firdeto%2F&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hojClORdOoJtcW8pt162xhoVOkFpDSAlHFdpi4ixj9U%3D&amp;reserved=0> [3 - instagram] <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.instagram.com%2Flifeatirdeto%2F%3Fhl%3Den&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SBEqwhWg5Wsp2LhpAqZh5JBYbVqaXvF6X0O1shAvBCU%3D&amp;reserved=0> [4 - youtube] <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fchannel%2FUCwgT0-wMbEqx3qLfrPIEnRg&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=a9wID1YYPeFdVXijSjIDOCdAJJ%2FcAIA7T1md1y%2FQj8o%3D&amp;reserved=0> [6 - facebook] <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FJoinIrdeto%2F&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=urIrDp3t2mZKOMMewzbWZiv6hS3v%2FYg%2FGgNGhkHzL2U%3D&amp;reserved=0> [7] <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FIrdeto%3Fref_src%3Dtwsrc%255Egoogle%257Ctwcamp%255Eserp%257Ctwgr%255Eauthor&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C8f5afeb9e53b4b11f9b808d87b63fcf5%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637395016659854203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6rPAMHp%2FoV4OnZlM8rx43YOkNtzFsD60KTLHvTwDi8E%3D&amp;reserved=0>

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.






Adding an out of tree driver

Lawrence King
 

Adding an out of tree board is easy, I just set the variable BOARD_ROOT and the build system happily finds my_custom_board. This is nicely described by following the links from here:  https://docs.zephyrproject.org/latest/application/index.html#boards

 

Now I want to do the same for my_custom_sensor_driver. Is there a variable I can set (like SENSOR_ROOT) that will find my out of tree sensor driver? Unfortunately the documentation at https://docs.zephyrproject.org/2.3.0/samples/application_development/out_of_tree_driver/README.html is a little sparse.

 

How do I include an out of tree sensor driver?

 

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.

 

 

 


Updated Event: Zephyr Project: APIs #cal-invite

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

Zephyr Project: APIs

When:
Tuesday, 3 November 2020
5:00pm to 6:00pm
(UTC+00:00) UTC
Repeats: Weekly on Tuesday

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


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

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

Reminder: Zephyr Project: APIs

When: Tuesday, 27 October 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
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 

781 - 800 of 8204