Date   

Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

Hi.

 

I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him).

 

Andrzej

 

From: devel@... [mailto:devel@...] On Behalf Of vikrant8051
Sent: Wednesday, May 16, 2018 11:51 AM
To: devel@...; users@...
Subject: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage

 

Hi,

 

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

 

Thank You !!

 

 

 

 

 


Clarity on subsystem definition and PMIC device

dhguja@gmail.com
 

Hello All,
          I am starting to design a driver for PMIC device in Zephyr. I am trying to figure out how to place this driver implementation. PMIC devices usually has multiple functionalities on single chip like Voltage Regulators, Battery Charger, Fuel Gauge, Display, Haptic, LED driver etc. 

My doubts are as following :

1. What will be the definition of a Subsystem in Zephyr (I am not able to find under documentation)? From what i understood, if a driver has multiple functionalities then instead of crowding the general include folder this get a separate directory structure under "subsys". 

2. Is there any API definitions planned for PMIC devices? or these PMIC devices can already be categorized under existing Driver structure. Since some of the functionalities like Fuel Gauge, Charger can already be implemented under "sensor.h" and LED under "led.h". But if i am implementing a PMIC driver i am not sure whether to handle them all separately under PMIC structure or spread across the existing APIs.? 

It would be helpful if you can point me to similar multi functional drivers currently in Zephyr. 

Thank you for the support.

Regards,
Dhananjay G J


Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Thu, May 17, 2018, vikrant8051 wrote:
Is #BluetoothMesh stack completely independent from persistence storage
mechanism used by #SettingLayer ?
Mesh will work with any settings backend (currently FCB and NFFS, and in
the future with NVS).

Johan


Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Andrzej,

Is #BluetoothMesh stack completely independent from persistence storage mechanism used by #SettingLayer ?

If yes, then only it will possible.  😃

Thank You !!

On Thu, May 17, 2018 at 1:28 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Hi.

 

I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him).

 

Andrzej

 

From: devel@... [mailto:devel@lists.zephyrproject.org] On Behalf Of vikrant8051
Sent: Wednesday, May 16, 2018 11:51 AM
To: devel@...; users@...
Subject: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage

 

Hi,

 

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

 

Thank You !!

 

 

 

 

 



Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Nathan Miller
 

Pawel,

this is what I'm seeing in dmesg:

[1281987.068423] usb 1-1-port4: unable to enumerate USB device
[1281987.760149] usb 1-1.4: new full-speed USB device number 86 using ehci-pci
[1281993.003844] usb 1-1.4: device descriptor read/all, error -110
[1281993.100525] usb 1-1.4: new full-speed USB device number 87 using ehci-pci
[1281998.224837] usb 1-1.4: device descriptor read/64, error -110
[1282025.058682] usb 1-1.4: new full-speed USB device number 88 using ehci-pci
[1282030.207060] usb 1-1.4: device descriptor read/64, error -110
[1282045.840180] usb 1-1.4: device descriptor read/64, error -110
[1282046.028229] usb 1-1.4: new full-speed USB device number 89 using ehci-pci
[1282051.216492] usb 1-1.4: device descriptor read/64, error -110

It definitely looks like something isn't right. This is what happens when I connect the device running the DFU sample compiled from your branch.

On Wed, May 16, 2018 at 9:16 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Carles Cufi
 

Hi Pawel,

 

The issue with the timeout is a well known one. I think Johann had a proposal, but first we need the stable driver to be on master.

 

Carles

 

From: Zadrożniak, Paweł
Sent: 16 May 2018 16:16
To: Nathan Miller <nathan.miller@...>
Cc: Cufi, Carles <carles.cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages: http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Zadrożniak, Paweł <Pawel.Zadrozniak@...>
 

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

Thank You !!






Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Nathan Miller
 

Pawel,

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available


On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:
Thanks Pawel and Carles. I'll pull that branch down and test it out!

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: Setting a default public MAC address in Zephyr HCI samples

Nathan Miller
 

Yes Carles, that is what we're trying to do. I've gone ahead and forked the repo so that I can change the reset function to apply the public MAC stored in the UICR.

On Mon, May 14, 2018 at 10:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

So let me get this straight, you program the address into the UICR during production, and then you want the controller to read it from there right?

 

In that case unfortunately you will need to modify the actual controller code. The only currently supported feature in that regard is for the Host to read the *FICR* address that comes with every Nordic chip. The other option is to also store the address in your Host IC during production of course.

 

Thanks,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Sent: 11 May 2018 19:52
To: Cufi, Carles <carles.cufi@...>
Cc: users@...


Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

That's correct Carles, we wanted the MCU to set the MAC instead of relying on the host, which cannot read the programmed MAC in the UICR. I was trying to avoid modifying the HCI code directly, hoping for something I could do from main.c, since the HCI spec makes mention of a non-volatile default value. If that's not possible, I can add the call to ll_addr_set into hci_init.

 

On Fri, May 11, 2018 at 10:33 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>


Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>

Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


Zephyr news, 14 May 2018

Marti Bolivar
 

Hello,

This is the 14 May 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

An HTML version is available here:

https://opensourcefoundries.com/blog/2018/05/14/zephyr-news-20180514/

Contents are broken down like this:

- **Highlights**
- Important changes: ABI/API breaks and some features
- New features: non-exhaustive descriptions of new features
- Bug fixes: non-exhaustive list of fixed bugs
- **Individual changes**: a complete list of patches, sorted
chronologically and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers changes in Zephyr between these two
commits (inclusive):

- c5615aad ("doc: change https://zephyrproject.org/doc refs"), merged
2 May 2018

- 1b038f29 ("Bluetooth: GATT: Make BT_GATT_CHARACTERISTIC declare its
value"), merged 14 May 2018

Important Changes
-----------------

New Watchdog API:

Continuing the Zephyr Long Term Support (LTS) goal of having stable driver
APIs, the watchdog.h interface was overhauled and re-worked. The
wdt_enable(), wdt_get_config(), wdt_set_config() and
wdt_api_reload() routines are still around for now, but have been
deprecated. Users of the watchdog API will want to switch to the new
routines documented in include/watchdog.h instead.

A driver using the new API was merged for the nRF SoC family's watchdog
peripheral. This driver uses device tree.

Menuconfig is now in Python:

The previously experimental Python menuconfig implementation has replaced
the C tools, following the addition of symbol search and jump-to-definition
features.

Users who were building the C tools in order to run menuconfig must use
the new Python tools instead. Windows users need to install a new
dependency via pip (by re-running "pip3 install -r
scripts/requirements.txt") before using this program. Mac and Linux users
do not require any additional dependencies.

Zephyr's use of Kconfig includes additional features not present in
the language implemented by the C tools. Somewhat confusingly,
documentation for these features was added to the board porting guide:

http://docs.zephyrproject.org/porting/board_porting.html#kconfig-extensions

This is a significant change, in that it now makes Zephyr development
possible on Windows in the native cmd.exe or Powershell shells, without any
additional Unix-specific toolchains or environments.

Storage API changes:

A variety of storage-related API changes were merged. These mostly are used
to enable new features.

The Kconfig knob which enables the storage_partition flash partition
(see http://docs.zephyrproject.org/devices/dts/flash_partitions.html)
was renamed from CONFIG_FS_FLASH_MAP_STORAGE to
CONFIG_FS_FLASH_STORAGE_PARTITION. This rename was done because use of
the storage partition does not require the flash_map module.

The filesystem API's struct fs_mount_t can now store references to
storage devices of arbitrary type in its storage_dev field; it was
previously restricted to a struct device*, but is now a void*. This
change was made to enable additional layers of indirection between this
field and the backing device.

The disk_access.h API was modified to support simultaneous use of multiple
disk interfaces. The old disk_access_ram.c and disk_access_flash.c have
seen a corresponding refactor; their globally available functions are now
hidden behind instances of the new struct disk_info and struct
disk_operations structures introduced in this change. The external FAT
file system library now supports multiple volumes.

The filesystem subsystem now supports multiple mounted instances of a
filesystem. As a result of these changes, the fs/fs_interface.h API no
longer assumes that either FAT or NFFS file systems are being used.

Bluetooth bt_storage removed in favor of settings API:

The bt_storage API was removed, as it provided features now enabled by the
settings subsystem using CONFIG_BT_SETTINGS. Users of this API will need
updates.

The Bluetooth shell and mesh and mesh_demo samples now have settings
support, as demonstrations of using the API.

Bluetooth Mesh support for the settings API required some refactoring to
expose previously hidden symbols to the storage API. There are some
tradeoffs, particularly related to managing flash wear when storing the
local sequence number and replay protection list; refer to the help for the
new CONFIG_BT_MESH_SEQ_STORE_RATE and BT_MESH_RPL_STORE_TIMEOUT options
for details.

Using this API requires a larger system workqueue stack size; the present
recommended size when using this API is now 2 KB, double its default value.

One additional alternative to using the settings API is the new
bt_set_id_addr() routine, which allows applications to set their identity
addresses in a manner similar to the bt_settings API.

Features
--------

Arches:

ARMv8-M MCUs with the Main Extension now have support for hardware-based
main stack overflow protection. The relevant Kconfig option to enable the
feature is CONFIG_BUILTIN_STACK_GUARD.

x86 CPUs can now grant user space access to the heap when using the newlib
C library.

Documentation:

In something of a "meta" development, documentation was added for how
to write Zephyr documentation:

http://docs.zephyrproject.org/contribute/doc-guidelines.html

Drivers and Device Tree:

The YAML device tree bindings for SPI now include an optional cs-gpios
property, which can be used to generate GPIO chip select definitions.

The bindings for ST's SPI-based BTLE nodes now require irq-gpios and
reset-gpios properties. The names of such devices are now only present in
Kconfig if a new CONFIG_HAS_DTS_SPI_PINS selector is unset.

There are two new Kconfig symbols, CONFIG_HAS_DTS_GPIO and
CONFIG_HAS_DTS_GPIO_DEVICE, which respectively allow declaring that the
GPIO driver supports device tree, and that drivers which need GPIOs do as
well. Currently, only the STM32 and MCUX GPIO drivers select
CONFIG_HAS_DTS_GPIO.

DT-based GPIO support for the NXP i.MX7 M4 SoC was added.

The mcux DSPI driver now uses device tree; SPI bindings were added to the
SoC files appropriately to enable this change. This driver also now
supports KW40/41Z SoCs.

The LED driver subsystem now has system call handlers for user mode
configurations.

The USB device controller driver for STM32 devices now supports all STM32
families, among a variety of other improvements to enable USB support on
STM32 MCUs in a variety of families. Board support was also added for
olimexino_stm32 and stm32f3_disco.

The pinmux subsystem no longer supports user mode access. This subsystem's
drivers lack sufficient input validation to prevent a malicious userspace
from accessing unauthorized memory through API calls. A proper fix will
require developing a specification for the subsystem, and updating existing
drivers to do appropriate input validation.

Altera HAL drivers can now be run on Zephyr. Such a driver for the Nios-II
modular scatter-gather DMA (mSGDMA) peripheral was merged, from the Altera
SDK v17. This was used to add a shim driver using Zephyr's dma.h API.

Networking:

The LWM2M implementation was significantly refactored and cleaned up. Once
nice benefit of this work is a 3KB RAM savings when running an LWM2M
client.

The network interface core now supports net_if_ipv4_select_src_addr() and
net_if_ipv4_get_ll() routines for accessing IPv4 source addresses.

Each struct net_pkt now uses one less byte of space, thanks to an
optimization in the size of its _unused field.

Testing:

The test case documentation now describes best practices for developing a
test suite, and how to list and skip test cases; see
http://docs.zephyrproject.org/subsystems/test/ztest.html for details.

Various tests were converted to use the ztest API, along with other
cleanups, renames, and Doxygen fixups added to the test suite.

Bug Fixes
---------

A build issue on sam_e70 was fixed.

An off-by-one error in the ARM MPU buffer validation routine was fixed.

A dedicated routine for incrementing the sequence number in the Bluetooth
Mesh implementation was added; in addition to fixing race conditions, this
is used by Mesh's settings subsystem integration in order to persist
sequence numbers to flash.

A Bluetooth Mesh bug affecting sequence number calculation in the Friend
queue was fixed.

Fixes to the TI ADC108S102 driver; VL53L0X, LSM6DSL, and HTS221 sensor
drivers; and QMSI UART driver were merged.

Fixes for using the FXOS8700, FXAS21002, and MCR20A drivers on NXP SoCs
were merged.

User mode heap access was fixed for applications which use the newlib C
library. User mode applications also no longer allow the stack sentinel
debugging feature to be enabled. This change was made because
CONFIG_USERSPACE implies separate and more robust stack protection
mechanisms.

The networking traffic class map from packet priorities to traffic classes
was fixed to comply with the IEEE 802.1Q specification.

The websocket implementation was refactored to avoid unnecessary tricky
calculations, resolving Coverity warnings.

The http_client sample was fixed in cases when TLS is enabled; previously,
this application overflowed a stack in this use case.

The mcumgr smp_svr sample's build was fixed.

The echo_server sample works on CC2520 again, along with other improvements
on that board. The CC3220sf board's linker map was also fixed.

The echo_server sample works on frdm_kw41z again, after other changes went
in that caused a stack overflow.

Various fixes and refactoring patches were merged to the
extract_dts_includes.py script, which generates code used by Zephyr from
the final device tree produced during an application build.

Individual Changes
==================

Patches by area (232 patches total):

- Arches: 20
- Bluetooth: 38
- Boards: 18
- Build: 5
- Continuous Integration: 8
- Device Tree: 9
- Documentation: 13
- Drivers: 29
- External: 4
- Kernel: 1
- Libraries: 2
- Maintainers: 3
- Miscellaneous: 1
- Networking: 22
- Samples: 5
- Scripts: 13
- Storage: 6
- Testing: 35

Arches (20):

- 4073db79 arch: nios2: Add _nios2_dcache_flush_no_writeback() routine
- 4a41f42e arch: arm: set interrupt stack protection with MSPLIM
- 91dc3bd0 arch: arm: ignore stack pointer limit checks during HF and NMI
- 8d1b013f arch: arm: thread built-in stack guard implementation
- e8e76ae4 arch: Add imx7d_m4 gpio definitions
- 3d691988 arm_mpu: fix off-by-one in mpu_buffer_validate
- 7f271b86 cc3220sf: soc: Update PRCM call to allow use of ROM API
- 55979aa3 arm: Add more flash and ram size options to i.MX RT MPU config
- dd26f285 arch: arm: add synchronization point after Stack Pointer switch
- fc76839b x86: grant user mode access to newlib heap
- 197e2773 arch: arm: improve description of ARMV7_M_ARMV8_M_MAINLINE option
- 47564a09 arch: arm: feature consistency checks for Cortex M regs
- 816e3d87 arch: stm32l4: add HAL_Delay for hal library hooks
- e81d9b98 arch: nxp dts bindings: Set IP clock name to matching clock
controller
- c136a107 soc: sam_e70: Mpu regions should include SRAM regions.
- b493f484 arch: arm: soc: Cleanup Kconfig inclusion per SoC
- 071212be arch: arm: atmel_sam: Fixup build issue on sam_e70
- c7dd4f55 nxp_kinetis: Enable mcux dspi driver on kw40/41z socs
- a88e31d2 nxp_kinetis: Remove unused dspi irq defines from soc.h
- 329c00dc arch/soc/st_stm32: Move STM32Cube HAL core funtions

Bluetooth (38):

- 6a71a69f Bluetooth: GATT: Fix CCC handling
- 8dd37fa7 Bluetooth: Mesh: Fix sequence number in Friend queue
- b997a283 Bluetooth: Introduce skeleton for settings-based storage
- d22b7c9f Bluetooth: Remove bt_storage API
- 470349c2 Bluetooth: settings: Add support for per-submodule handlers
- f36ea836 Bluetooth: Add support for persistent pairing keys storage
- 6af5d1cd Bluetooth: Compress bt_keys struct
- a2955436 Bluetooth: shell: Add settings support
- 10fabcd0 Bluetooth: Mesh: Move IV Update defines to net.h
- f7e780a7 Bluetooth: Mesh: Increase visibility of net & app key helpers
- ca10b6bc Bluetooth: Mesh: Remove redundant initialization
- 2be496a0 Bluetooth: Mesh: Create dedicated helper for incrementing seq
- 9540f7d5 Bluetooth: Mesh: Add skeleton for persistent storage
- 1c846651 Bluetooth: Mesh: Add storage APIs for core network values
- 3f30d12c Bluetooth: Mesh: Remove redundant 'provisioned' variable
- 43c7ef39 Bluetooth: Mesh: Move network startup operations to common function
- be7fe55b Bluetooth: Mesh: Introduce measures to avoid too frequent
flash writes
- cc3830f8 Bluetooth: Mesh: Fix resetting configuration model state
- 31afd189 Bluetooth: Mesh: Add support for clearing persistent network storage
- 5b01cb1a Bluetooth: Introduce new bt_set_id_addr() API
- c1c5f3d9 Bluetooth: Mesh: Expose destination address in bt_mesh_msg_ctx
- f6a687c0 Bluetooth: GATT: Add support to persistent CCC config
- ace19814 Bluetooth: Mesh: Convert RPL storage timer into a generic one
- 9e2189c4 Bluetooth: Mesh: Introduce generic storage timer
- b7078e14 Bluetooth: Mesh: Perform storage clearing also through delayed work
- 8703ffad Bluetooth: Mesh: Redesign element and storage info for models
- c3d5a0da Bluetooth: Mesh: Support for storing model bindings persistently
- dde2db56 Bluetooth: Mesh: Support for storing model subscriptions persistently
- efb68ca2 Bluetooth: Mesh: Support for storing model publication persistently
- 44bd5687 Bluetooth: Mesh: Support for storing heartbeat publication
persistently
- 59239032 Bluetooth: Mesh: Support for storing common configuration states
- 53c85cf8 Bluetooth: Mesh: Fix updating RPL for locally originated messages
- e2404214 Bluetooth: Mesh: Fix sequence number restoring
- da82976e Bluetooth: samples/mesh_demo: Add support for settings-based storage
- 88dfd399 Bluetooth: Mesh: Remove sequence number from bt_mesh_provision()
- 4f4afce5 Bluetooth: Remove unused rx_prio_queue
- 318a1758 Bluetooth: GATT: Introduce BT_GATT_ATTRIBUTE
- 1b038f29 Bluetooth: GATT: Make BT_GATT_CHARACTERISTIC declare its value

Boards (18):

- cdd108f6 boards: intel_s1000_crb: Assign Intel VID and PID for S1000 CRB
- 4388f6f3 boards/arm/nrf52_blenano2: add storage flash partition
- 31a2ac87 board: add gpio support for colibri_imx7d_m4 board
- f64657e8 frdm_k64f: Fix pin name typos in the board doc
- 6be824d0 cc3220sf: Fix linker map and dtsi to ensure full 256K SRAM size
- 77e9e27d mimxrt1050_evk: Add config to select code linking location
- 65e96eef boards: disco_l475_iot1: enable XSHUT master control
- 38d2567e boards: olimexino_stm32: Add USB support
- 80d69ea4 boards: stm32f3_disco: Add USB support
- 2acb1287 boards: disco_l475_iot1/dts: add gpios in bt controller node
- 90ac25f7 boards: dts: Add fxos8700 interrupt bindings and fix sensor sample
- 9cd36c7b boards: dts: Add fxas21002 interrupt bindings and fix sensor sample
- 87b95184 hexiwear_k64: Fix whitespace in dts.fixup
- ed1ab61e frdm_kw41z: Configure spi0 pinmuxes and update board doc accordingly
- ae2a9b0f boards: Select HAS_DTS_SPI_DEVICE on kinetis boards
- 0d1beb2f boards: dts: Add mcr20a bindings and fix networking samples
- 4edae077 boards/arm/olimexino_stm32: Add disconnect gpio in usb node
- 5ce10f1d boards: arm: nrf52_blenano2: Add I2C default config

Build (5):

- 60b01f3f kconfig: Refactor kconfig.py to use __main__ and argparse
- 890a5a5a kconfig: Remove targets specific to the C implementation
- 11952a60 kconfig: Remove the C Kconfig implementation
- ac7f2239 kconfig: Mention that checkconfig.py lacks Kconfiglib 2 support
- 547ed9b5 kconfig: Make 'source' non-globbing and use 'gsource'

Continuous Integration (8):

- 73440ead sanitycheck: device handler, allow running tests on real hw
- e0a6a0b6 sanitycheck: parse test results and create detailed report
- d3384fb7 sanitycheck: cleanup handler class
- 37f9dc5c sanitycheck: simplify argument passing and use global options
- a3abe967 sanitycheck: do not count duplicate tests
- 61e2163e sanitycheck: support skipped tests, enhance device handler
- 10776c44 ci: remove pyserial install
- de7fc9de sanitycheck: we need pyserial for sanitycheck

Device Tree (9):

- 16399a64 dts: mimxrt1050_evk: Add external memory nodes
- 47fe4ee7 dts/arm/st: Add USB support for stm32f070/72
- 3bbe87e1 dts/arm/st: Add usbotg_fs node to stm32l4 DT
- 11a70647 dts: spi: Add optional cs-gpios to the spi bus controller binding
- 00376f08 dts/bindings: Add reset and irq gpios to "st,spbtle-rf" yaml
- d2d4cea0 dts: nxp_kinetis: Add spi bindings for kinetis dspi and
update soc nodes
- b3107fd1 dts/bindings/usb: Add disconnect gpio in st,stm32-usb.yaml
- c0b47213 dts/arm/st: Add USB support for stm32l072/73
- 83e4947c dts: nrf: Expand nRF DTS to support watchdog

Documentation (13):

- c5615aad doc: change https://zephyrproject.org/doc refs
- 2c8a3835 doc: DRAFT start for 1.12 release notes
- 7a6f7136 doc: process test documentation
- 418cc0ea doc: Update for menuconfig.py
- 5443d065 doc: fix colibri_imx7d_m4 board documentation
- 18859171 doc: flatten doxygen-generated HTML structure
- 850b218e doc: document best practices for main.c suite declaration
- 3e136b4d doc: fix misspellings in doc and Kconfig files
- 0d12b74a doc: fix references to mailing lists
- 930dbd5d doc: Document Kconfig extensions and Zephyr-specific behavior
- 486c5a54 doc: add doc writing guides w/common usages
- 7ac624e7 doc/subsystem/settings: fix wrong settings_handler field names
- a869f875 doc: Mention that dependencies can be checked in menuconfig

Drivers (29):

- 15447fa1 drivers: dma: Add dma driver for Nios-II MSGDMA core
- 26babfc6 drivers: led: Add system call handler support
- d1bd3a6f dma: define and document the source and dest adjust enum.
- a4208365 pinmux: remove user mode access
- a0c3aadd uart_qmsi: fix possible divide-by-zero
- 97ccf99b ti_adc108s102: fix verification off-by-one
- 5dc2ab4f ti_adc108s102: validate num_entries
- b83d0782 sensor: vl53l0x: make xshut pin control optional
- 77c0456d sensors: hts221: Fix a crash due to bad device init
- 921bfeb0 drivers: usb_dc_stm32: Add support for all STM32 families
- 55dada25 drivers: usb_dc_stm32: Add usb disconnect pin support
- ad530033 drivers: pinmux_stm32l4x: add usb otg pinmux
- b1478518 drivers: usb_dc_stm32: use HSI48 if available
- e2b27d82 drivers: usb_dc_stm32: enable VDDUSB if needed
- 57904102 gpio: dts: Introduce Kconfig symbols to convey GPIO dts support
- 3fbc7c58 spi: Wrap instance configs consistently with ifdefs
- d749feb6 spi: Fix missing "depends on !HAS_DTS_SPI"
- cae90744 spi: Refactor mcux dspi driver to use dts
- 2fbb4d35 spi: Refactor mcux dspi shim driver to use clock control interface
- 4e324e21 usb: dfu: fix 'this area can not be overwritten'
- f47b9c2f drivers/usb/device: Remove USB DISCONNECT gpio options
- 3ff4065c drivers: sensors: lsm6dsl: Fix array overrun
- 2a55fcf6 drivers/usb/usb_dc_stm32: Provide EP_TYPE_* defines for L0
- c9d5b561 drivers/usb_dc_stm32: HSI48 requires VREFINT in L0
- f6a96979 drivers/stm32l0x_ll_clock: Enable SYSCFG in clock_control
- 87d62441 drivers/stm32f0x_ll_clock: Enable SYSCFG in clock_control
- aec46596 drivers/usb_dc_stm32: Check if SYSCFG is enabled
- 0c2ef4ea drivers: watchdog: Watchdog API redesign
- 30a24e8a drivers: watchdog: Add shim for nrfx WDT driver

External (4):

- 4f68b4dc ext: hal: altera: Add modular Scatter-Gather DMA HAL driver
- 9b5fa895 ext: hal: altera: Add wrapper function for Altera HAL runtime API
- e2024171 ext: hal: ti: simplelink: ensure ROM APIs used in board port file
- c5f1b0b8 ext: hal: ti: simplelink: Add comments to CMakeLists.txt

Kernel (1):

- abf77ef7 subsys: debug: Fix stack sentinel dependencies

Libraries (2):

- a8532122 newlib: libc-hooks: Print "exit" message with newline
- 42a2c964 newlib: fix heap user mode access for MPU devices

Maintainers (3):

- d9ff55f2 CODEOWNERS: add more owners to tests/*
- def4a4c1 CODEOWNERS: more fix and and updates
- 6b5ded4c CODEOWNERS: Add pfalcon for various net directories

Miscellaneous (1):

- 81bac40b gitignore: let git ignore *.patch file only to top tree

Networking (22):

- 12855789 net: if: Add functions to get correct IPv4 address
- 3e16be3c net: lwm2m: refactor engine_get_obj to be more useful
- 44c9b79a net: lwm2m: clear lwm2m_obj_path obj in string_to_path
- cf55b70b net: lwm2m: fix error code in read and write handlers
- f80c52d6 net: lwm2m: introduce LWM2M_HAS_PERM macro
- aa9a24aa net: lwm2m: remove LWM2M_OP_NONE flag and renumber the rest
- 42717a97 net: lwm2m: use BIT macro instead of LWM2M_OP_BIT
- b6ca731b net: lwm2m: remove unused CONFIG_LWM2M_BOOTSTRAP_PORT config
- f038d35a net: lwm2m: remove unused LWM2M_PEER_PORT define
- af8a0b1a net: tc: Proper packet priority to traffic class mapping
- 9681f3d0 net: Update bit size of _unused member in struct net_pkt
- 7359c5b1 net: lwm2m: Do not use snprintk() to get debugging token
- 8c2362a6 net: ip: context: Merge send_data() into the only caller
- bba1fe8c net: lwm2m: Re-order lwm2m object structs for memory alignment
- 2027c10a net: lwm2m: remove "path" from object and resource instances
- bc7a5d3a net: lwm2m: relocate/memory align notification_attrs struct
- 573c1f77 net: lwm2m: improve return errors from update_attrs()
- 6ef46e3f net: lwm2m: remove attr_list from obj, obj_inst and res_inst structs
- ad13866f net: lwm2m: remove "used" from observe_node
- fc8d0935 net: lwm2m: lower default maximum observes from 20 to 10
- e81b9043 net: websocket: Simplify building of responses
- 03f9f664 net: websocket: Revise generation of Sec-WebSocket-Accept header

Samples (5):

- 33eb03a8 samples: net: https-client: Increasing main stack size
- 94136829 samples: subsys: usb: Set disk name Kconfig option
- c913c671 smaples/mgmt/mcumgr/smp_svr: fix missing nffs.h header
- 7d9631e6 samples/net: Fix echo_client for cc2520
- d536ffa6 samples/echo_server: Increased stack sizes for testing OT on kw41z

Scripts (13):

- b737fcb9 scripts: kconfig: Add incremental search to menuconfig
- 7229a9a5 scripts: kconfig: Switch 'menuconfig' over to menuconfig.py
- 133bad78 scripts: install windows-curses package on Windows
- 65f0c679 checkpatch: downgrade COMPLEX_MACRO to a warning
- 27d34926 menuconfig: Increase indent and make Unicode more robust
- e099f381 scripts: extract_dts_includes: rename arguments for easier reading
- 081c9c3b scripts: extract_dts_includes: Generate'_0' defines only when needed
- 97a1ea22 scripts: extract_dts_includes: Fix extract_cells for a list
- ded17a91 scripts: extract_dts_includes: Fix extract_controller for a list
- 9272a3e5 scripts: extract_dts_includes: remove prefix argument
- 93d3a427 scripts: extract_includes_dts: Remove usage of cell_string
yaml attribute
- 295c1d85 menuconfig: Fix rendering of long prefilled edit box string
- e24788eb menuconfig: Make search more flexible and search prompts

Storage (6):

- 4954fe06 subsys: fs: fix generic storage partition selection
- f4dcb459 subsys: fs: fcb: fix - crc write size not aligned
- b99ff6f9 subsys: fs: Extend storage_dev type beyond 'struct device'
- 2b5b7da9 subsys: disk: Add support for multiple disk interfaces
- dd5449a7 subsys: fs: Add the support for multiple instances of fs
- cf06bc58 susbsys: settings: optimized fcb compression for deleted entry

Testing (35):

- 542f10de tests: net: ip: Refactor and add IPv4 tests
- 11120bf1 tests: remove comma from whitelist
- ee1e9886 tests: boards: altera_max10: Add test for Nios-II MSGDMA soft IP
- 7a587eea tests: document skipping tests and listing them
- cc6f8b52 tests: fp_sharing: Fix definition of PI_NUM_ITERATIONS
- 12c5bfaf tests : ipv6_fragment : Avoid NULL pointer access
- 93109f2d tests: enhance test meta-data/improve test naming
- efb52c5b tests: neighbor: use ztest asserts
- 478f6807 tests: http: call tests via ztest macro
- ee6b8761 tests: ipv6: convert to ztest
- 8603f7a4 tests: flash_map: use proper test name
- fa0a670d tests: integration: do not run test on hw
- bc672895 tests: remove duplicate tests
- 540e11ce tests: rename main test to main.c
- c57326e1 tests: fix doxygen comments
- c44f4e0e tests: alert: add doxygen documentation
- a279403c tests: remove dot after PASS|FAIL
- 01b83175 tests: subsys: fs: Add changes to support multiple FS instance
- c239ea70 tests: subsys: fs: Add test for FAT FS dual instance case
- 7174546b tests: threads: Document description for test cases
- 8e8cb4a9 tests: doxygen comment cleanup
- 2a64fe66 ztest: prints newline after failure message
- 79a0fa68 tests: mem_protect: Add memory domain testcases
- 0e8daafd tests kernel pending: unitialized variable
- 5ef03f5f tests: spi_loopback: Add frdm_kw41z configuration
- 3be0c56d tests/subsys/settings/fcb: add deleted settings compression test
- d76cc488 tests: net: checksum_offload: Check for valid UDP_HDR
- 5575487d tests: posix: Fix sigevent initialization
- f71e497d tests: net: ipv6: Add assert for net_if_config_ipv6_get
- 7e0d1d27 tests: lib: rbtree: Clarify increment of variable
- 93e71ab0 tests: net: mgmt: Do not allocate link address from stack
- d5515658 tests: net: coap: Fix uninitialized memory access
- 47638440 tests: net: tcp: IPv4 header was not initialized
- e8d0571b tests: net: tcp: Remove unnecessary code
- c9898097 tests: watchdog: Add new test implementation


Re: Setting a default public MAC address in Zephyr HCI samples

Carles Cufi
 

So let me get this straight, you program the address into the UICR during production, and then you want the controller to read it from there right?

 

In that case unfortunately you will need to modify the actual controller code. The only currently supported feature in that regard is for the Host to read the *FICR* address that comes with every Nordic chip. The other option is to also store the address in your Host IC during production of course.

 

Thanks,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Sent: 11 May 2018 19:52
To: Cufi, Carles <carles.cufi@...>
Cc: users@...
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

That's correct Carles, we wanted the MCU to set the MAC instead of relying on the host, which cannot read the programmed MAC in the UICR. I was trying to avoid modifying the HCI code directly, hoping for something I could do from main.c, since the HCI spec makes mention of a non-volatile default value. If that's not possible, I can add the call to ll_addr_set into hci_init.

 

On Fri, May 11, 2018 at 10:33 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>


Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>

Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


Re: [Zephyr-devel] about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Johan,

As per nrf52840_pca10056.dts file last 16KB is used for persistent data storage.

To calculate FLASH life time, I have to understand what is going on at background (at #FCB layer).

This is my understanding,

There should be 2 parts in memory (which starts from 0xFC000)
PART-A : to save variables id
PART-B:  to save combo of {variable's data, variable's data length, variable id} in this sequence

If so then,

    editing any variable's data ==>> writing variable attributes in this sequence: {variable's data, variable's data length(1 byte), variable id(1 byte)} in Part-B


    reading  ==>> data retrieve from latest entry

(Here in Part-B, Last byte is always variable id)

Till this, am I right ?
If so, then what is size of current PART-B ?

Where I will find documentation which shows architectural implementation behind #Setting as well as #FCB layer?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

is $zephyr/tests/subsys/settings/src only option to getting started with #Setting layer ?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thank You !!
 


On Mon, May 14, 2018 at 1:24 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Sat, May 12, 2018, vikrant8051 wrote:
> How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be
> depend upon setting layer which is newly introduce concept or gonna
> completely independent as part of App layer ?

The currently implementation is purely based on settings, so you can
just register your own settings subpath to store app-specific
information. I'd advise to use something else than "bt/" however, since
that's what we use for stack-internal data and wouldn't want application
code to conflict with it (or different apps to confict with each other).

> There are 2 types of Persistent Data in context of #BluetoothMesh:
> 1) constant
>      (which is created & saved during provisioning & configuration )
>
> 2) non - constant
>   ( eg. Sequence no., Models states etc.)
>
> Is current implementation using same sector of flash for both ?

It all uses the same settings API, i.e. no attempt is currently made to
split things into different categories.

I think you might have a slightly wrong idea of the different categories
of data that mesh has. The only really constant values with Mesh 1.0 are
the unicast address and the device key. And even these will change if
you do a node reset and reprovision.

Everything else, including Network Key, Application Keys, etc can and
often will change during the lifetime of the mesh network. So if you
really want to try to categorize the data into two two categories it'd
be frequently changing data, and infrequently changing (but not
constant) data.

> If Node is receiving 100 messages a day in which destination address could
> be it's own or group address for which it has subscribed, then what will be
> life of that device  (assuming SoC flash supports 10K erase cycles) as per
> FCB based current implementation ?

It depends on how you've configured CONFIG_BT_MESH_SEQ_STORE_RATE. The
nice thing with the settings API is that we could use its "export"
callback together with settings_save() to support power-loss triggered
flash writing on boards that have a small backup power source and are
able to give an interrupt of some sorts when the main one gets lost.

> Is there any documentation which shows approximate life span of
> #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or
> upcoming #NVS layer) ?

No, and as I said, it depends on your configuration and your hardware. I
welcome you to do these calculations for some reference implementation
(hardware included) and share your results with the Zephyr project
community!

> If we use #meshctl, then sometimes it complete provisioning but it fails
> after executing
>
> --> appkey-add 1
>
> & something constantly goes on #meshctl terminal. Is anyone observed same ?

I haven't. Btw, may I ask that you in the future split different topics
to different emails? Otherwise these unrelated things may get lost on
people.

> If provisioning or configuration fails & there is no hardware reset button
> to trigger bt_mesh_reset() in that case, how to push device into factory
> reset mode ? Any Idea ?

That depends on your hardware. If it doesn't have any buttons then you
need to reflash it, I suppose.

> My solution is to add vendor state (Let it be Foo) which will be set to "1"
> only after proper provisioning & configuration by provisioner App.
>
> On device side following logic will get execute after every reset
>
>    if(Foo == 0)
>    {
>         bt_mesh_reset( );
>    }

The problem with that is that it's not really generalizable, since
there's no standard way of detecting (on the configuration server side)
when the configuration phase is complete. The best that you might be
able to do in a generic way is to have some timer that's reset after
each received configuration message, and when it expipres assume that
the configuration phase is complete. This is e.g. what the Zephyr LPN
implementation already supports in order to determine when to reduce the
scanning duty cycle (see CONFIG_BT_MESH_LPN_AUTO_TIMEOUT).

Johan


Re: [Zephyr-devel] about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Sat, May 12, 2018, vikrant8051 wrote:
How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be
depend upon setting layer which is newly introduce concept or gonna
completely independent as part of App layer ?
The currently implementation is purely based on settings, so you can
just register your own settings subpath to store app-specific
information. I'd advise to use something else than "bt/" however, since
that's what we use for stack-internal data and wouldn't want application
code to conflict with it (or different apps to confict with each other).

There are 2 types of Persistent Data in context of #BluetoothMesh:
1) constant
(which is created & saved during provisioning & configuration )

2) non - constant
( eg. Sequence no., Models states etc.)

Is current implementation using same sector of flash for both ?
It all uses the same settings API, i.e. no attempt is currently made to
split things into different categories.

I think you might have a slightly wrong idea of the different categories
of data that mesh has. The only really constant values with Mesh 1.0 are
the unicast address and the device key. And even these will change if
you do a node reset and reprovision.

Everything else, including Network Key, Application Keys, etc can and
often will change during the lifetime of the mesh network. So if you
really want to try to categorize the data into two two categories it'd
be frequently changing data, and infrequently changing (but not
constant) data.

If Node is receiving 100 messages a day in which destination address could
be it's own or group address for which it has subscribed, then what will be
life of that device (assuming SoC flash supports 10K erase cycles) as per
FCB based current implementation ?
It depends on how you've configured CONFIG_BT_MESH_SEQ_STORE_RATE. The
nice thing with the settings API is that we could use its "export"
callback together with settings_save() to support power-loss triggered
flash writing on boards that have a small backup power source and are
able to give an interrupt of some sorts when the main one gets lost.

Is there any documentation which shows approximate life span of
#BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or
upcoming #NVS layer) ?
No, and as I said, it depends on your configuration and your hardware. I
welcome you to do these calculations for some reference implementation
(hardware included) and share your results with the Zephyr project
community!

If we use #meshctl, then sometimes it complete provisioning but it fails
after executing

--> appkey-add 1

& something constantly goes on #meshctl terminal. Is anyone observed same ?
I haven't. Btw, may I ask that you in the future split different topics
to different emails? Otherwise these unrelated things may get lost on
people.

If provisioning or configuration fails & there is no hardware reset button
to trigger bt_mesh_reset() in that case, how to push device into factory
reset mode ? Any Idea ?
That depends on your hardware. If it doesn't have any buttons then you
need to reflash it, I suppose.

My solution is to add vendor state (Let it be Foo) which will be set to "1"
only after proper provisioning & configuration by provisioner App.

On device side following logic will get execute after every reset

if(Foo == 0)
{
bt_mesh_reset( );
}
The problem with that is that it's not really generalizable, since
there's no standard way of detecting (on the configuration server side)
when the configuration phase is complete. The best that you might be
able to do in a generic way is to have some timer that's reset after
each received configuration message, and when it expipres assume that
the configuration phase is complete. This is e.g. what the Zephyr LPN
implementation already supports in order to determine when to reduce the
scanning duty cycle (see CONFIG_BT_MESH_LPN_AUTO_TIMEOUT).

Johan


about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi, 

How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be depend upon setting layer which is newly introduce concept or gonna completely independent as part of App layer ?

------------------------------------------------------------------------------------------------------------------

There are 2 types of Persistent Data in context of #BluetoothMesh:
1) constant 
     (which is created & saved during provisioning & configuration )

2) non - constant 
  ( eg. Sequence no., Models states etc.) 

Is current implementation using same sector of flash for both ? 

Will it be secured during #DFU_OTA ?
Where it is define for every Board? Where I can get details about flash memory sector which here acting like EEPROM ?


------------------------------------------------------------------------------------------------------------------

If Node is receiving 100 messages a day in which destination address could be it's own or group address for which it has subscribed, then what will be life of that device  (assuming SoC flash supports 10K erase cycles) as per FCB based current implementation ?

Is there any documentation which shows approximate life span of #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or upcoming #NVS layer) ?

------------------------------------------------------------------------------------------------------------------


If we use #meshctl, then sometimes it complete provisioning but it fails after executing 

--> appkey-add 1

& something constantly goes on #meshctl terminal. Is anyone observed same ? 

[In that case, I have to reflash the firmware or reset the board & send node-reset command via #meshctl.]

------------------------------------------------------------------------------------------------------------------

If provisioning or configuration fails & there is no hardware reset button to trigger bt_mesh_reset() in that case, how to push device into factory reset mode ? Any Idea ?

My solution is to add vendor state (Let it be Foo) which will be set to "1" only after proper provisioning & configuration by provisioner App.
 
On device side following logic will get execute after every reset

   if(Foo == 0)
   {
        bt_mesh_reset( );
   }

------------------------------------------------------------------------------------------------------------------


Thank You !!





Re: Setting a default public MAC address in Zephyr HCI samples

Nathan Miller
 

That's correct Carles, we wanted the MCU to set the MAC instead of relying on the host, which cannot read the programmed MAC in the UICR. I was trying to avoid modifying the HCI code directly, hoping for something I could do from main.c, since the HCI spec makes mention of a non-volatile default value. If that's not possible, I can add the call to ll_addr_set into hci_init.

On Fri, May 11, 2018 at 10:33 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>


Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>

Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Nathan Miller
 

Thanks Pawel and Carles. I'll pull that branch down and test it out!

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Zadrożniak, Paweł <Pawel.Zadrozniak@...>
 

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: Setting a default public MAC address in Zephyr HCI samples

Carles Cufi
 

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>
Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


Re: Setting a default public MAC address in Zephyr HCI samples

Carles Cufi
 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>
Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?

2141 - 2160 of 2941