Date   

Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

Carles Cufi
 

Hi Ashish,

 

Make sure of 2 things:

 

·         You are using CMake 3.4 or higher (cmake –version to check)

·         You have sourced zephyr-env.sh in the Zephyr tree before building MCUboot

 

Thanks,

 

Carles

 

From: ashish.shukla@... <ashish.shukla@...>
Sent: 06 April 2018 13:36
To: Cufi, Carles <Carles.Cufi@...>
Cc: users@...
Subject: Re: [Zephyr-users] [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

 

Hi Carles,

Thanks a lot for pointing us to such a detailed documentation. However, while following through doc, I ran into an issue.  When I tried to build MCUboot in it's present form, after adding a prj.cnf file, and adding following line at the starting of CMakeLists.txt

include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(NONE)

policy CMP0002 of cmake is violated. How can this issue be resolved ?

 


 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 

 

On Fri, Apr 6, 2018 at 2:22 PM, Cufi, Carles <carles.cufi@...> wrote:

Hi Ashish,

 

Here is the published documentation:

 

http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> On Behalf Of ashish.shukla@...
Sent: 21 March 2018 05:15
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

 

Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Any help regarding the same would be of great help.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 

 


Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

ashish shukla <ashish.shukla@...>
 

Hi Carles,

Thanks a lot for pointing us to such a detailed documentation. However, while following through doc, I ran into an issue.  When I tried to build MCUboot in it's present form, after adding a prj.cnf file, and adding following line at the starting of CMakeLists.txt

include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(NONE)

policy CMP0002 of cmake is violated. How can this issue be resolved ?





--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Fri, Apr 6, 2018 at 2:22 PM, Cufi, Carles <carles.cufi@...> wrote:

Hi Ashish,

 

Here is the published documentation:

 

http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> On Behalf Of ashish.shukla@...
Sent: 21 March 2018 05:15
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

 

Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Any help regarding the same would be of great help.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 



Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

Carles Cufi
 

Hi Ashish,

 

Here is the published documentation:

 

http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> On Behalf Of ashish.shukla@...
Sent: 21 March 2018 05:15
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] Firmware over the air (FOTA) and FCB support in 1.11.0

 

Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Any help regarding the same would be of great help.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 


Re: /zephyr/samples/drivers/i2c_fujitsu_fram not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi,

As I can see in the i2c_nrf5.c and Kconfig.nrf5, the configuration that needs to be done is still NRF5 and CONFIG_I2C_NRF5_0_GPIO_SDA_PIN. If Nordic fellows change nomenclature, they should have compiled their drivers at least once. Also, I'm using a stable commit of zephyr. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Tue, Apr 3, 2018 at 12:13 PM, ashish.shukla@... <ashish.shukla@...> wrote:
Hello all,

I'm trying to compile /zephyr/samples/drivers/i2c_fujitsu_fram for interfacing an I2C device with nrf52840.

Edited prj.conf as following,

CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_I2C=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

now, it's producing a number of compilation errors. I'm attaching screen shot of the terminal for reference

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi



Hardware PWM driver support for nrf52

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello everyone,

There is software PWM driver for nrf52 series controllers, I need hardware PWM driver for the same.

Can I expect support for hardware PWM driver in upcoming time ? 

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Stuck with BT mesh, what is wrong with provisioning ? ...

Axel <anvivaldi27@...>
 

Hi All,

I am trying a basic example with nrf51 mesh. (samples/bluetooth/mesh)
After enabling mesh debugging I can see my nrf51 board is sending mesh advertising packets 
with type (0x2B - Mesh Beacon) len 24 Value: 0x00DDDD00000000000….
Also I can see these packets in Nrf Connect application with random source address appearing every second.
But I see nothing in SiliconLabs Bluetooth Mesh Application (v 1.1.0) provision tab.
and changed:


static const struct bt_mesh_comp comp = { .cid = CID_INTEL, .elem = elements, .elem_count = ARRAY_SIZE(elements), };

to #define CID_INTEL 0x0002


And commented out OOB provision:

static const struct bt_mesh_prov prov = { .uuid = dev_uuid, //.output_size = 4, //.output_actions = BT_MESH_DISPLAY_NUMBER, //.output_number = output_number, .complete = prov_complete, .reset = prov_reset, };

It still not possible to see any information about mesh node even in the
latest Bluez 5.49 meshctl 
(discover-unprovisioned on)

I am out of clue what is wrong :(

Using latest: 
Attached screenshot:



Thank you.


/zephyr/samples/drivers/i2c_fujitsu_fram not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello all,

I'm trying to compile /zephyr/samples/drivers/i2c_fujitsu_fram for interfacing an I2C device with nrf52840.

Edited prj.conf as following,

CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_I2C=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

now, it's producing a number of compilation errors. I'm attaching screen shot of the terminal for reference

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: NXP MCUX RTC implementation

Michael Hope
 

Hi Franco.  I don't know of any technical limitation, but from what I've seen so far the Zephyr community takes a broad but shallow approach - for example, I've been adding support for the SAMD21 used in the Arduino Zero so I've focused on the SPI, USB, Flash, and GPIO drivers that I need and skipped others like PWM or ADC.

-- Michael

On Wed, 28 Mar 2018 at 16:20 Franco Saworski <franco.saworski@...> wrote:
Hi,

we at blik are working with Zephyr on one of our hardware units, and would like to use a lowpower mechanism along with an RTC wakeup.

Unfortunately RTC implementations are sparse, with only one implementation present. Is there a technical limitation or reason for this?
As far as I understand, SoC lowpower implementations are omitted in Zephyr, because they are usually usecase specific. I can't imagine the same for RTC.

Furthermore, we are looking for someone to develop the RTC driver and ultimately upstream it, as a small paid project. Please feel free to message me, if you're interested.

Kind regards,
Franco Saworski


--

Embedded Engineer

blik GmbH
transparent real-time data

Leonrodstraße 68 | 80636 München
HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.
_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: [Zephyr-devel] #BluetoothMesh URI provisioning #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Fri, Mar 30, 2018, Vikrant More wrote:
Is Zephyr going to introduce feature so that beacon will broadcast URI for
unprovisioned #BluetoothMesh DEVICEs ?
This is already supported using the "const char *uri" member of struct
bt_mesh_prov.

Johan


#BluetoothMesh URI provisioning #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi, 

Is Zephyr going to introduce feature so that beacon will broadcast URI for unprovisioned #BluetoothMesh DEVICEs ?

Or it is simply replacing DEVICE_NAME (means Zephyr ) to something like mentioned in #BluetoothMesh specification at 8.4.2 ( Beacon : 0070cf7c9732a345b691494810d2e9cbf44020d97478b3 ) ?

-------------------------------------------------------------------------------------------------------------
As per my understanding,

URI beacon = DEVICE's UUID + some part of Hash which is generated from "URI data" which is stored at URL 

URI data = ECDH public key of DEVICE ( which is common to all DEVICEs under particular category)

Am I right ?

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

Please throw some light on URI beacon based secure provisioning.

Thank You !!


NXP MCUX RTC implementation

Franco Saworski <franco.saworski@...>
 

Hi,

we at blik are working with Zephyr on one of our hardware units, and would like to use a lowpower mechanism along with an RTC wakeup.

Unfortunately RTC implementations are sparse, with only one implementation present. Is there a technical limitation or reason for this?
As far as I understand, SoC lowpower implementations are omitted in Zephyr, because they are usually usecase specific. I can't imagine the same for RTC.

Furthermore, we are looking for someone to develop the RTC driver and ultimately upstream it, as a small paid project. Please feel free to message me, if you're interested.

Kind regards,
Franco Saworski


--

Embedded Engineer

blik GmbH
transparent real-time data

Leonrodstraße 68 | 80636 München
HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.


Re: USB HID sample

Johannes Hutter
 

Hey Yannis,

thanks for the answer. I think, I just figured it out now. I forgot to set the pinmux for USB OTG in my custom board file. Now the endpoint gets registered and seems to work.

Best regards,

Joe



On 27.03.2018 09:49, Yannis Damigos wrote:

I tried to run the USB HID sample on a STM-based device and ran into some problems. I get a usage fault caused by a division by zero. This actually happens in the ST HAL, where a division by the MPS of the USB enpoint is done. The MPS is actually 0 when the sample does the USB write. Is there something missing in the sample? When turning the logging in the USB subsystem on, I can also see, that the Enpoints 0x00 and 0x80 are configured, but not the HID endpoint (on 0x83). the set_callback function is however called in the stm driver.

Would be great if someone could point me in the right direction.

Hi Joe,

I will try to test the sample on my boards in the next days. The default HID endpoint is 0x81. Is it configured?

Best regards,
Yannis 

--

Johannes Hutter | Embedded Software Engineer
Mail: johannes@...


Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320


Re: USB HID sample

Yannis Damigos
 

I tried to run the USB HID sample on a STM-based device and ran into some problems. I get a usage fault caused by a division by zero. This actually happens in the ST HAL, where a division by the MPS of the USB enpoint is done. The MPS is actually 0 when the sample does the USB write. Is there something missing in the sample? When turning the logging in the USB subsystem on, I can also see, that the Enpoints 0x00 and 0x80 are configured, but not the HID endpoint (on 0x83). the set_callback function is however called in the stm driver.

Would be great if someone could point me in the right direction.

Hi Joe,

I will try to test the sample on my boards in the next days. The default HID endpoint is 0x81. Is it configured?

Best regards,
Yannis 


Re: USB HID sample

Michael Hope
 

Hi Johannes.  I don't know if this is helpful, but I'm successfully using the HID code on the SAMD21.  Doesn't mean there's not a bug though :)

-- Michael

On Mon, 26 Mar 2018 at 20:09 Johannes Hutter <johannes@...> wrote:

Hello guys,


I tried to run the USB HID sample on a STM-based device and ran into some problems. I get a usage fault caused by a division by zero. This actually happens in the ST HAL, where a division by the MPS of the USB enpoint is done. The MPS is actually 0 when the sample does the USB write. Is there something missing in the sample? When turning the logging in the USB subsystem on, I can also see, that the Enpoints 0x00 and 0x80 are configured, but not the HID endpoint (on 0x83). the set_callback function is however called in the stm driver.

Would be great if someone could point me in the right direction.


Thanks and Best Regards,

Joe

--

Johannes Hutter | Embedded Software Engineer
Mail: johannes@...


Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: Custom per project flash runner

Marti Bolivar
 



On Mon, Mar 26, 2018 at 2:10 PM, Roman Tataurov <diytronic@...> wrote:
Hello!
 
26.03.2018, 01:27, "Marti Bolivar" <marti@...>:
Hi Roman,
 
You can specify a flash and debug runner without touching any board files by setting BOARD_FLASH_RUNNER and/or BOARD_DEBUG_RUNNER in the CMake command line when generating a build system.
 
 
Damn ... of course. So easy. Feel stupid :(

Not at all! Thanks for asking. I'm sure others were wondering too. This area needs better documentation.
 
Thank you Marti! It is really a solution.

I'm glad.

Thanks,
Marti
 
 
Here is an example branch, in which I have created a "dummy" runner:
 
 
Here is the commit which adds the extra runner, which just prints the command instead of acting on hardware:
 
 
Here is an example shell session where the flash and debug runners are set at CMake time and then used later using "ninja flash", "ninja debug", and "ninja debugserver". I have used the nrf52_pca10040 board, but it should work with any board.
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ cmake -GNinja -DBOARD=nrf52_pca10040 -DBOARD_FLASH_RUNNER=dummy -DBOARD_DEBUG_RUNNER=dummy ..
CMake Deprecation Warning at /home/mbolivar/src/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.
 
  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)
 
 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.11.99
[snip]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mbolivar/src/zephyr/samples/hello_world/build
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja
[1/118] Generating always_rebuild
Building for board nrf52_pca10040
[113/118] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       44732 B       512 KB      8.53%
            SRAM:       11388 B        64 KB     17.38%
        IDT_LIST:         132 B         2 KB      6.45%
[118/118] Linking C executable zephyr/zephyr.elf
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja flash
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Flashing nrf52_pca10040
command: flash
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debug
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debug
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debugserver
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debugserver
 
 
Hope this helps. Please let me know if you still have problems.
 
Thanks,
Marti
 
On Sun, Mar 25, 2018, 3:48 PM Roman Tataurov <diytronic@...> wrote:
Hello!

I there some way to specify custom flash runner command instead of default one used for board.
For example I have a flasher what work with my board, but does not specified with board configuration.
Tried to play with set(BOARD_FLASH_RUNNER - it work if change it inside board config, but found no way to overwrite it in project files, not touching board files.

--
Roman Tataurov

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
 
 
-- 
Roman Tataurov
 


Re: Custom per project flash runner

Roman Tataurov
 

Hello!
 
26.03.2018, 01:27, "Marti Bolivar" <marti@...>:
Hi Roman,
 
You can specify a flash and debug runner without touching any board files by setting BOARD_FLASH_RUNNER and/or BOARD_DEBUG_RUNNER in the CMake command line when generating a build system.
 
 
Damn ... of course. So easy. Feel stupid :(
Thank you Marti! It is really a solution.
 
Here is an example branch, in which I have created a "dummy" runner:
 
 
Here is the commit which adds the extra runner, which just prints the command instead of acting on hardware:
 
 
Here is an example shell session where the flash and debug runners are set at CMake time and then used later using "ninja flash", "ninja debug", and "ninja debugserver". I have used the nrf52_pca10040 board, but it should work with any board.
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ cmake -GNinja -DBOARD=nrf52_pca10040 -DBOARD_FLASH_RUNNER=dummy -DBOARD_DEBUG_RUNNER=dummy ..
CMake Deprecation Warning at /home/mbolivar/src/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.
 
  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)
 
 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.11.99
[snip]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mbolivar/src/zephyr/samples/hello_world/build
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja
[1/118] Generating always_rebuild
Building for board nrf52_pca10040
[113/118] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       44732 B       512 KB      8.53%
            SRAM:       11388 B        64 KB     17.38%
        IDT_LIST:         132 B         2 KB      6.45%
[118/118] Linking C executable zephyr/zephyr.elf
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja flash
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Flashing nrf52_pca10040
command: flash
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debug
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debug
 
 
plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debugserver
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debugserver
 
 
Hope this helps. Please let me know if you still have problems.
 
Thanks,
Marti
 
On Sun, Mar 25, 2018, 3:48 PM Roman Tataurov <diytronic@...> wrote:
Hello!

I there some way to specify custom flash runner command instead of default one used for board.
For example I have a flasher what work with my board, but does not specified with board configuration.
Tried to play with set(BOARD_FLASH_RUNNER - it work if change it inside board config, but found no way to overwrite it in project files, not touching board files.

--
Roman Tataurov

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
 
 
-- 
Roman Tataurov
 


USB HID sample

Johannes Hutter
 

Hello guys,


I tried to run the USB HID sample on a STM-based device and ran into some problems. I get a usage fault caused by a division by zero. This actually happens in the ST HAL, where a division by the MPS of the USB enpoint is done. The MPS is actually 0 when the sample does the USB write. Is there something missing in the sample? When turning the logging in the USB subsystem on, I can also see, that the Enpoints 0x00 and 0x80 are configured, but not the HID endpoint (on 0x83). the set_callback function is however called in the stm driver.

Would be great if someone could point me in the right direction.


Thanks and Best Regards,

Joe

--

Johannes Hutter | Embedded Software Engineer
Mail: johannes@...


Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320


Re: Custom per project flash runner

Marti Bolivar
 

Hi Roman,

You can specify a flash and debug runner without touching any board files by setting BOARD_FLASH_RUNNER and/or BOARD_DEBUG_RUNNER in the CMake command line when generating a build system.

Here is an example branch, in which I have created a "dummy" runner:


Here is the commit which adds the extra runner, which just prints the command instead of acting on hardware:


Here is an example shell session where the flash and debug runners are set at CMake time and then used later using "ninja flash", "ninja debug", and "ninja debugserver". I have used the nrf52_pca10040 board, but it should work with any board.

plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ cmake -GNinja -DBOARD=nrf52_pca10040 -DBOARD_FLASH_RUNNER=dummy -DBOARD_DEBUG_RUNNER=dummy ..
CMake Deprecation Warning at /home/mbolivar/src/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)


-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.11.99
[snip]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mbolivar/src/zephyr/samples/hello_world/build


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja
[1/118] Generating always_rebuild
Building for board nrf52_pca10040
[113/118] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       44732 B       512 KB      8.53%
            SRAM:       11388 B        64 KB     17.38%
        IDT_LIST:         132 B         2 KB      6.45%
[118/118] Linking C executable zephyr/zephyr.elf


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja flash
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Flashing nrf52_pca10040
command: flash


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debug
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debug


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debugserver
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debugserver


Hope this helps. Please let me know if you still have problems.

Thanks,
Marti


On Sun, Mar 25, 2018, 3:48 PM Roman Tataurov <diytronic@...> wrote:
Hello!

I there some way to specify custom flash runner command instead of default one used for board.
For example I have a flasher what work with my board, but does not specified with board configuration.
Tried to play with set(BOARD_FLASH_RUNNER - it work if change it inside board config, but found no way to overwrite it in project files, not touching board files.

--
Roman Tataurov

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Custom per project flash runner

Roman Tataurov
 

Hello!

I there some way to specify custom flash runner command instead of default one used for board.
For example I have a flasher what work with my board, but does not specified with board configuration.
Tried to play with set(BOARD_FLASH_RUNNER - it work if change it inside board config, but found no way to overwrite it in project files, not touching board files.

--
Roman Tataurov


What is need of addition authentication in case of #BluetoothMesh if ECDH public key exchanged over OOB ? #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi, 

If #BluetoothMesh DEVICE ECDH-public key (oob public key) is exchanged over OOB channel then what is further need of authentication using input-OOB or output-OOB or static-OOB ?

Thanks,

2101 - 2120 of 2783