Date   

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?


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

Carles Cufi
 

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.


Setting a default public MAC address in Zephyr HCI samples

Nathan Miller
 

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

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 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: BLE throughput / RF test tools?

Carles Cufi
 

Hi David,

It depends. If you are using the hci_uart or hci_usb apps then you will need to find a throughput tool in your Host (BlueZ typically).
If you however are using a combined build (Host + Controller) then you can use the Bluetooth shell to test it as show in this video:

https://www.youtube.com/watch?v=H-rUGKCln0A

Note that this only works with 2 Zephyr boards.

Regards,

Carles

-----Original Message-----
From: users@... <users@...> On
Behalf Of via Lists.Zephyrproject.Org
Sent: 09 May 2018 19:55
To: users@...
Cc: users@...
Subject: [Zephyr-users] BLE throughput / RF test tools?

Hi,

Checking in if there are any existing tools out ther to run throughput
testing over BLE

i.e. usb -> uart -> nrf52
to either
--> mac/ios device (hid or midi-ble for lowest poll-intervals)
or
--> nordic ev-kit or any other rf device / reference dongle s


best david


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

Thomas Li Fredriksen
 

From the errors, it seems that dfu-util is rejecting the file-extension.

The NRF imgtool is actually generating a zip containing three files: mainfest.json, hello.dat, hello.bin.

I have embedded this tool into cmake with a custom command, used with a nRF52832-board:

add_custom_target( ${fname}.zip DEPENDS ${fname}.bin
            COMMAND ${NRFUTIL} pkg generate --application ${fname}.bin --application-version 1 --hw-version 52 --sd-req 0x8c --key-file ${NRFUTIL_KEY} ${fname}.zip
)


I would guess updating the last argument of your imgtool.py-call should do the trick:

~/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.zip


On 10. mai 2018 23:52, Nathan Miller wrote:

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.


-- 
Thomas Li Fredriksen, Data Scientist

ContinYou AS

Langgata 28

NO-4306 Sandnes, Norway

 

Tel: +47 51 66 51 66

Dir: +47 45 22 10 55 Mob: +47 45 22 10 55



thomas@...   www.continyou.no


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

Nathan Miller
 

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: Zephyr hci_usb nrf52840

Nathan Miller
 

Thanks for the suggestion Carles. I just tried the UART example and I was able to connect to the device and read a characteristic, so it definitely seems like it might be a transport issue. Do you have any suggestions for further debugging?

On Wed, May 9, 2018 at 10:34 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

In order to be able to ascertain if the problem is in the USB transport layer (which could be since it’s relatively new and untested) could you please try instead to use the hci_uart application, assuming you are using our nRF52840 development kit, so that we see if the problem disappears when using a UART transport instead of an USB one.

 

You can find instructions on how to do so here:

 

http://docs.zephyrproject.org/samples/bluetooth/hci_uart/README.html#using-the-controller-with-bluez

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of nathan.miller@...
Sent: 02 May 2018 00:11
To: users@...
Subject: [Zephyr-users] Zephyr hci_usb nrf52840

 

Hi all,

I am trying to test an nRF52840 as a USB HCI using the Zephyr hci_usb sample project. I'm running into an issue in which devices I attempt to connect to will disconnect themselves after about 30 seconds, every time I attempt to connect. When I watch btmon, I see this:

< ACL Data TX: Handle 0 flags 0x00 dlen 7                  #15 [hci0] 17.698158
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
< HCI Command: Disconnect (0x01|0x0006) plen 3             #16 [hci0] 49.737234
        Handle: 0
        Reason: Remote User Terminated Connection (0x13)

it appears that the device never receives or never responds to the Exchange MTU Request. I'm using bluetoothctl to establish the connection. I've tried two different device types and both exhibit the problem, and when I attempt to use the internal adapter on my host, I do not have this problem with either device. My host is an x86_64 machine running Ubuntu 16.04.4, kernel version 4.13.0-39, and BlueZ version 5.49. I've attempted it with both a Nordic PCA10056 board and a Rigado BMD-340 dev board. Has anyone seen this before? I'm not entirely sure what steps to take next to debug this. I can provide any additional info necessary.


BLE throughput / RF test tools?

David Eriksson <david@...>
 

Hi,

Checking in if there are any existing tools out ther to run throughput testing over BLE

i.e. usb -> uart -> nrf52
to either
--> mac/ios device (hid or midi-ble for lowest poll-intervals)
or
--> nordic ev-kit or any other rf device / reference dongle s


best david


Re: Zephyr hci_usb nrf52840

Carles Cufi
 

Hi Nathan,

 

In order to be able to ascertain if the problem is in the USB transport layer (which could be since it’s relatively new and untested) could you please try instead to use the hci_uart application, assuming you are using our nRF52840 development kit, so that we see if the problem disappears when using a UART transport instead of an USB one.

 

You can find instructions on how to do so here:

 

http://docs.zephyrproject.org/samples/bluetooth/hci_uart/README.html#using-the-controller-with-bluez

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of nathan.miller@...
Sent: 02 May 2018 00:11
To: users@...
Subject: [Zephyr-users] Zephyr hci_usb nrf52840

 

Hi all,

I am trying to test an nRF52840 as a USB HCI using the Zephyr hci_usb sample project. I'm running into an issue in which devices I attempt to connect to will disconnect themselves after about 30 seconds, every time I attempt to connect. When I watch btmon, I see this:

< ACL Data TX: Handle 0 flags 0x00 dlen 7                  #15 [hci0] 17.698158
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
< HCI Command: Disconnect (0x01|0x0006) plen 3             #16 [hci0] 49.737234
        Handle: 0
        Reason: Remote User Terminated Connection (0x13)

it appears that the device never receives or never responds to the Exchange MTU Request. I'm using bluetoothctl to establish the connection. I've tried two different device types and both exhibit the problem, and when I attempt to use the internal adapter on my host, I do not have this problem with either device. My host is an x86_64 machine running Ubuntu 16.04.4, kernel version 4.13.0-39, and BlueZ version 5.49. I've attempted it with both a Nordic PCA10056 board and a Rigado BMD-340 dev board. Has anyone seen this before? I'm not entirely sure what steps to take next to debug this. I can provide any additional info necessary.


Re: scan_Adv example for scanning

Carles Cufi
 

Hi there,

 

The scan_adv app does not print the received packets, but you can do so by adding a printk() statement in the scan_cb().

You can use the Bluetooth shell to do the same (tests/bluetooth/shell), and if you take a look at subsys/bluetooth/shell/bt.c (function device_found) you can see how to print the information.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of swapnil
Sent: 01 May 2018 17:00
To: users@...
Subject: [Zephyr-users] scan_Adv example for scanning

 

Hello,
I was trying out an example scan_Adv with an existing configuration to see the packets coming from a beacon, as there is no dedicated example available for scanning.,
I was expecting scanner to display all the received packets. I am using minicom to see the information.
my goal is to extract data from the received packet . is there any way to do so?
Thank you in advance,

regards,
Swapnil


Re: [Zephyr-devel] Kconfig changes on master

jack ma <assangema@...>
 

Hi,
What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?
Are they alternative or dependent?

Thanks.

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide







Re: [Zephyr-devel] Kconfig changes on master

Carles Cufi
 

Hi there,

 

CMake is the build system, Kconfig is the configuration system. Kconfig is run by CMake as one of the first things it does in order to figure out what needs to be built and how.

 

More information can be found here:

http://docs.zephyrproject.org/application/application.html#cmake-details

http://docs.zephyrproject.org/application/application.html#application-configuration

 

Regards,

 

Carles

 

From: jack ma <assangema@...>
Sent: 08 May 2018 12:29
To: Cufi, Carles <carles.cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Kconfig changes on master

 

Hi,

What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?

Are they alternative or dependent?

 

Thanks.

 

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide



 


[Zephyr-user] Read connection RSSI on nRF52840

전형욱
 

Hello,

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)
It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon



Re: zephyr thread.

Leandro Pereira
 

Novello,

On 04/18/2018 12:58 PM, novello wrote:
I waold like to know if there is an application note that explain haw to make an application with  some thread that are static.Every thread will have an fixed address space.
The address space at the moment is fixed in Zephyr. A feature to fuzz the initial stack pointer is available (CONFIG_STACK_POINTER_RANDOM) to provide some unpredictability at runtime, but that's disabled by default.

We have plans to support address space layout randomization on devices with memory management units (MMUs), but this requires some design changes that will happen only in upcoming releases. On systems with memory protection units (MPUs), which comprises the majority of devices supported by Zephyr, there isn't much that can be done WRT randomizing the memory layout besides what we have now.


Every task will have a Statically Allocated RAM?
When creating a thread with k_thread_create(), a pointer to a memory block to be used as a stack has to be passed to the function. A dynamic memory allocator (e.g. malloc) is not required for Zephyr to function. Any sample found in the "samples" directory that calls this function should be sufficient to guide you.

Leandro

2181 - 2200 of 2965