|
Re: mcuboot + dfu-util on nRF52840 not able to update firmware
Thanks Pawel and Carles. I'll pull that branch down and test it out!
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.
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
Hi.
I’ll try to run the example later with my work-in-progress driver and check if it works.
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
toggle quoted messageShow quoted text
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.
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
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
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
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
toggle quoted messageShow quoted text
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.
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
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
toggle quoted messageShow quoted text
Hi.
I’ll try to run the example later with my work-in-progress driver and check if it works.
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
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?
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-rUGKCln0ANote 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
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
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
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?
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
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
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
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
Hi, What is the relationship cmake and kconfig ? both of them can be used to configure Zephyr ? Are they alternative or dependent?
Thanks.
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
toggle quoted messageShow quoted text
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
|
|
|
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
|
|
|
