Date   

Re: Using SPI_SLAVE on STM32

Tomasz Bursztyka
 

It has not been rebased against latest SPI API changes, thus why it
can't be merged. But it's a fine PR besides that.

Tomasz

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/52
00
You probably need the first patch, and the second is an example how
to
do it. Note however the API has changed a bit, you'll have to
check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?





Re: Using SPI_SLAVE on STM32

Armando Visconti
 

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,
Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/5200
You probably need the first patch, and the second is an example how to
do it. Note however the API has changed a bit, you'll have to check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?


Re: Using SPI_SLAVE on STM32

Tomasz Bursztyka
 

Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/5200
You probably need the first patch, and the second is an example how to
do it. Note however the API has changed a bit, you'll have to check.

Br,

Tomasz

Ciao guys,

I'm currently working on ArgonKey, which is a 96 board with a
STM32F412
plus a bunch of motion and environmental sensors.

I'm exploring the possibility to put in place the communication from
HiKey to ArgonKey and I noticed that the stm32 SPI environment
already
implements the SPI_SLAVE communication. Does somebody have already
tried
it out and know what the status is? Is there any example (doesn't
seem
so) where I can get a look from?

Thx,
Arm




Using SPI_SLAVE on STM32

Armando Visconti
 

Ciao guys,

I'm currently working on ArgonKey, which is a 96 board with a STM32F412
plus a bunch of motion and environmental sensors.

I'm exploring the possibility to put in place the communication from
HiKey to ArgonKey and I noticed that the stm32 SPI environment already
implements the SPI_SLAVE communication. Does somebody have already tried
it out and know what the status is? Is there any example (doesn't seem
so) where I can get a look from?

Thx,
Arm


Re: Support for ARM DS-5 compiler

Sebastian Boe
 

Hi,

building Zephyr with an LLVM-based compiler (like DS-5) was prototyped
but not finished in https://github.com/zephyrproject-rtos/zephyr/pull/5901.

Since then there has not been any activity. I'm not sure about the schedule.

Contributions are welcome :)

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Peder Møller <pedermoeller@gmail.com>
Sent: Friday, 4 May 2018 12:57:17 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Support for ARM DS-5 compiler

Are there any plans for including support in Zephyr for the ARM DS-5 compiler?

The getting started guide has some information about how to set up a 3rd party compiler

http://docs.zephyrproject.org/getting_started/getting_started.html#using-custom-and-3rd-party-cross-compilers

However, the example 3rd party compiler is also a GCC compiler.
I have not been successful in setting up the ARM DS-5 compiler for Zephyr using this information, but there was a rumour that the Zephyr project was working on built-in support for ARM DS-5.

Is anyone able to confirm this rumour?

Thanks and best regards,
Peder Møller.


Support for ARM DS-5 compiler

Peder Møller
 

Are there any plans for including support in Zephyr for the ARM DS-5 compiler?

The getting started guide has some information about how to set up a 3rd party compiler


However, the example 3rd party compiler is also a GCC compiler.
I have not been successful in setting up the ARM DS-5 compiler for Zephyr using this information, but there was a rumour that the Zephyr project was working on built-in support for ARM DS-5.

Is anyone able to confirm this rumour?

Thanks and best regards,
Peder Møller.


Re: Usage of generated dts *_GPIO_FLAGS

Erwan Gouriou
 

Hi Diego,


Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan


On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/



Re: Core407V STM32F407VET6 Board Definition

Yannis Damigos
 

Hi Waren,

CONFIG_GPIO_STM32=n in your core407v_stm32f407_defconfig disables the STM32
gpio driver.

Yannis


On Fri, May 4, 2018 at 5:53 AM Warren Gay <ve3wwg@gmail.com> wrote:

This is in reference to the MCU board
https://www.waveshare.com/wiki/Core407V

I have been able to build & flash the project in zsrc.tar.gz (below)
using the
board BOARD olimex_stm32_e407. The LEDs flash as expected.
However, when I try to use my own board definition (BOARD
core407v_stm32f407),
it builds but does not execute correctly (no LED flashing). Perhaps
someone
can point out something obviously wrong with my board definition.
Thanks, Warren
https://drive.google.com/open?id=10MFd3qMrX5062BkAz-mm3KdWUtUbcsLJ
(core407.tar.gz board defn)

https://drive.google.com/open?id=1p0TX3f30R2Rf6qKyBbci1xjRpApzz7he
(zsrc.tar.gz has blinky)


Usage of generated dts *_GPIO_FLAGS

Diego Sueiro
 

Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


Re: What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

HI Aaron,

This PDF may help developers who want to go with Zephyr #BluetoothMesh.

https://www.zephyrproject.org/wp-content/uploads/sites/38/2018/03/openiot_zephyr_lts_what_and_why.pdf

But following links are Silent about #BluetoothMesh
As per attached image, #LTS is going to release in June 2018.

So currently, I'm clueless & unfortunately have to go with stack provided by Silicon manufactures
which are Black Box & inherently complicated.  😥

 

On Fri, May 4, 2018 at 8:27 AM, Aaron Xu <overheat1984@...> wrote:
Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:
Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!








Re: What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

Aaron Xu
 

Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Core407V STM32F407VET6 Board Definition

Warren Gay <ve3wwg@...>
 

This is in reference to the MCU board https://www.waveshare.com/wiki/Core407V

I have been able to build & flash the project in zsrc.tar.gz (below) using the 
board BOARD olimex_stm32_e407. The LEDs flash as expected.

However, when I try to use my own board definition (BOARD core407v_stm32f407), 
it builds but does not execute correctly (no LED flashing). Perhaps someone
can point out something obviously wrong with my board definition.


What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Re: Networking API example code

Paul Sokolovsky
 

Hello Patrik,

As we were requested at the TSC meeting to keep the discussion public
at the devel mailing list, please let me re-route this conversation
there.

I also apologize for delayed response - there were public holidays
here. Please see responses below.

On Fri, 27 Apr 2018 15:10:18 +0300
Patrik Flykt <patrik.flykt@linux.intel.com> wrote:

Here is a fairly simple piece of C code that we can use to demonstrate
different networking APIs in Zephyr. It's simple, as the request was
to present the APIs in the Networking Forum next week. Of course a
more realistic example would be much more elegant, but then time
would be spent on deducing the internal flow of the program, which
will not create any more clarity on the matter.
As I mentioned in my previous mail (dated Apr 26,
https://lists.zephyrproject.org/g/devel/topic/examples_for_zstream/18100280),
Zephyr tree includes 5 ready socket examples which demonstrate socket
API from various angles and are known to work. I proposed to use one of
them to demonstrate TLS API approaches.

Your going forward with an adhoc example may leave an impression that
your API can't work with existing examples, and require an artificial
one - which is definitely not true.

But your going with a single-source-file example also hides what the
existing Zephyr socket samples are. They are fully self-contained
(albeit small and "toy") applications with build files included, and
these build files demonstrate thess apps working on both Zephyr and a
reference POSIX system (tested with Linux).

Samples for my Zstream API preserve this continuity. And that's where
your API would have problems. And I hope it's not just me who's keen to
see how you'd resolve that.

So, I hope you had time over the last week also convert one of the
samples at
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets
to your API and test it with both Zephyr and a POSIX system.

Oh, and btw, your sample code had a mistake, so couldn't work as is, I
had to fix it.


I was thinking that the code that is changed/added could be indicated
for example by color, so that the modifications needed by each API and
proposal would be easy to spot. As the code is quite short, it might
even be possible to squeeze the samples on two slide pages each. With
that we then can present the original example socket code below, the
Net App version, Zstream and socket option version in a reasonably
short time in an understandable way.
Fairly speaking, Zstream was at that stage - discussing individual
calls in a presentation-like manner circa beginning of February (and
that was done on github). The way I understood TSC's request is to
prepare 2 more or less real-world samples to compare 2 APIs. I didn't
try to squeeze mine into the presentation slides. I also let Github diff
viewer do the coloring:

https://github.com/pfalcon/zephyr/pull/2/commits/735ba51e56a191e45e9afb7f1a5e221976451e67

This is your sample, as-is from the mail.

https://github.com/pfalcon/zephyr/pull/2/commits/bc1dbb75c5f76739681f9d44eb755f50bb45bc2b

This adds missing connect() call, and build files for Zephyr and POSIX.
This represents a working, testable sample.

https://github.com/pfalcon/zephyr/pull/2/commits/8d2cf8da1fddf946ea8912a327e76d28e05fcaba

This shows the changes required to convert socket-based sample to
Zstream-based sample, still preserving buildability and functioning on
both Zephyr and POSIX.

(Links are valid until git rebase.)


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: STM32 ADC shim

Erwan Gouriou
 

Hi Anthony,

Easiest to start would be to use STM32Cube HAL to implement your shim layer.
If you feel more comfortable with ADC, you might want to use STM32Cube LL
layer, which will help you to implement a more integrated and lightweight driver.

For reference, you can have a look a serial driver, which should be the most
simple one using LL, or PWM for HAL. There are other quite good drivers using
LL or HAL but they are more complex to study.
There is also an on going work to push CAN driver, which uses HAL in a quite
limited way, but could be used to check what is needed to provide for Kconfig
and device tree.

Last, you'll find some examples on how to use STM32Cube LL and HAL APIs
in the packages you can download on www.st.com.

In any way, if you feel blocked or have questions, don't hesitate to ask for support
in this mailing list or provide an early version of your work with [DNM][RFC] tags
(Do Not Merge/Request For Comments) and request for review.

Good luck
Erwan


On 3 May 2018 at 05:43, Anthony Kreft <anthony.kreft@...> wrote:
I'm interested in working on a shim to enable the ADC driver on the STM32. What is the best way to get started with that? Are there any good pull requests I can use as reference? I think most confusing to me are the Kconfig and device tree requirements. If there are known issues with the ADC for STM32 in terms of integrating with the Zephyr driver, please let me know. Thanks for your help.

Regards,
Anthony



STM32 ADC shim

Anthony Kreft <anthony.kreft@...>
 

I'm interested in working on a shim to enable the ADC driver on the STM32. What is the best way to get started with that? Are there any good pull requests I can use as reference? I think most confusing to me are the Kconfig and device tree requirements. If there are known issues with the ADC for STM32 in terms of integrating with the Zephyr driver, please let me know. Thanks for your help.

Regards,
Anthony


Re: Add stm32flash to zephyr_flash_debug.py script

Armando Visconti
 

Hi Marti,

On 05/02/2018 05:43 PM, Marti Bolivar wrote:
Hi Armando,
I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io <http://groups.io> (which is unfortunate, I assumed that archives would be preserved).
I reproduce it here for your reference, hope it helps:
Thx very much,

I'll go thru it tomorrow!

Rgds,
Arm


Re: Add stm32flash to zephyr_flash_debug.py script

Marti Bolivar
 

Note also that the documentation for the class you will need to implement is here:


On Wed, May 2, 2018 at 11:43 AM, Marti Bolivar <marti@...> wrote:
Hi Armando,

I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io (which is unfortunate, I assumed that archives would be preserved).

I reproduce it here for your reference, hope it helps:

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


Thanks,
Marti


On Wed, May 2, 2018 at 11:39 AM, Armando Visconti <armando.visconti@...> wrote:
Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando






Re: Add stm32flash to zephyr_flash_debug.py script

Marti Bolivar
 

Hi Armando,

I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io (which is unfortunate, I assumed that archives would be preserved).

I reproduce it here for your reference, hope it helps:

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


Thanks,
Marti


On Wed, May 2, 2018 at 11:39 AM, Armando Visconti <armando.visconti@...> wrote:
Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando





Add stm32flash to zephyr_flash_debug.py script

Armando Visconti
 

Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando

3541 - 3560 of 8046