Date   

Re: ADC driver and power management API

Tomasz Bursztyka
 

Hi Piotr,

Good point. ADC API was designed some months before PM one, and was not revised once the later came in.

Sounds like you can throw a PR to remove these.

Thanks,

Tomasz

Hi all,

The ADC driver API specifies adc_enable / adc_disable functions. The doxygen documentation of adc_enable function states: "This routine enables the ADC hardware block for data sampling for the specified device".

This seems to be redundant / conflicts with Zephyr's power management subsystem API. Shouldn't the adc_enable / adc_disable functions be removed?

- Piotr



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



ADC driver and power management API

Piotr Mienkowski
 

Hi all,

The ADC driver API specifies adc_enable / adc_disable functions. The doxygen documentation of adc_enable function states: "This routine enables the ADC hardware block for data sampling for the specified device".

This seems to be redundant / conflicts with Zephyr's power management subsystem API. Shouldn't the adc_enable / adc_disable functions be removed?

- Piotr


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Boie, Andrew P
 

The deeper context here is that we have a number of timing-sensitive tests which sometimes fall over if the server running sanitycheck is heavily loaded. AFAICT, this is due to QEMU trying to synchronize the emulated system timer with the host workstation timer.

To date, nobody have been able to figure out a way to get QEMU to act differently. What we want is for the emulated system to be completely detached from the host system's sense of timing. Anyone who can figure this out, patches would be most welcome.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Nashif, Anas
Sent: Monday, August 14, 2017 8:39 AM
To: Paul Sokolovsky <paul.sokolovsky@linaro.org>; Maciej Debski <maciej.debski@rndity.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hi,
There was an issue in how we re-run sanitycheck on failed tests (retry) to eliminate false positive due to heavy load and Qemu not being able to deal with that. This is now fixed.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Monday, August 14, 2017 11:25 AM
To: Maciej Dębski <maciej.debski@rndity.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@rndity.com> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy would add, non-tests fail sooner or later too.) If you're sure it's random failure not related to your changes, then you just need to resubmit your pull request to trigger a new CI build. To resubmit a PR, its commit revisions should change. The easiest way to achieve that is to rebase on the latest master. If it happens that nobody pushed any new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision, and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
Best Regards,
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 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Nashif, Anas
 

Hi,
There was an issue in how we re-run sanitycheck on failed tests (retry) to eliminate false positive due to heavy load and Qemu not being able to deal with that. This is now fixed.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Monday, August 14, 2017 11:25 AM
To: Maciej Dębski <maciej.debski@rndity.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@rndity.com> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy would add, non-tests fail sooner or later too.) If you're sure it's random failure not related to your changes, then you just need to resubmit your pull request to trigger a new CI build. To resubmit a PR, its commit revisions should change. The easiest way to achieve that is to rebase on the latest master. If it happens that nobody pushed any new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision, and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
Best Regards,
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 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Paul Sokolovsky
 

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@rndity.com> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy
would add, non-tests fail sooner or later too.) If you're sure it's
random failure not related to your changes, then you just need to
resubmit your pull request to trigger a new CI build. To resubmit a PR,
its commit revisions should change. The easiest way to achieve that is
to rebase on the latest master. If it happens that nobody pushed any
new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision,
and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
Best Regards,
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


Nucleo f030r8 fails at QEMU Cortex M3 test

Maciej Dębski <maciej.debski@...>
 

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure, which is:
Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test / qemu_cortex_m3/tests/net/ieee802154/l2/test

As far as I believe, this test is not related to my board. I am not sure though. Could you give me some information on how I should react to this?
How can I correct this? What does the test mean? Is there a way to not test my code with it?

Thank you for help,
Maciej Dębski


Nucleo f030r8 fails at QEMU Cortex M3 test

Maciej Dębski <maciej.debski@...>
 

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure, which is:
Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test / qemu_cortex_m3/tests/net/ieee802154/l2/test

As far as I believe, this test is not related to my board. I am not sure though. Could you give me some information on how I should react to this?
How can I correct this? What does the test mean? Is there a way to not test my code with it?

Thank you for help,
Maciej Dębski


Re: Bluetooth Mesh - configuration server client and helth server client models

Johan Hedberg
 

Hi Jehudi,

On Fri, Aug 11, 2017, Laczen JMS wrote:
In the bluetooth mesh samples it is shown how to set-up and use the
configuration server and health server root models. Is there also an
example on how to use the configuration client and health client model ?
What are the routines that need to be defined for these models ?
The Client models would typically be operated by a device with a rich &
interactive user interface. As something like that is rarely found on
Zephyr-based device only the Server models are currently implemented.
For implementing client-side models, you could e.g. take example from
the mesh_demo app, which sends configuration messages to the local node
for self-configuration).

Johan


Bluetooth Mesh - configuration server client and helth server client models

laczenJMS
 

Hi,

In the bluetooth mesh samples it is shown how to set-up and use the configuration server and health server root models. Is there also an example on how to use the configuration client and health client model ? What are the routines that need to be defined for these models ?

Thanks, and kind regards,

Jehudi


Re: How to figure out the stack size for a thread?

Li, Jun R
 

Great! Thank you, Mike and Andrew!

 

From: Michael Rosen <michael.r.rosen@...>
Date: Thursday, August 10, 2017 at 11:41
To: "Li, Jun R" <jun.r.li@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] How to figure out the stack size for a thread?

 

Jun,

 

You can use CONFIG_STACK_USAGE to have the build system generate the .su files which summarize the stack usage (if computable at compile time) of all the functions in all the files. You can use this information to determine the max stack height a thread can reach so long as you know the deepest call path (and what functions are a part of it) but summing all of the static usages. I don’t know of an automated way to do this, but if someone else knows, please chime in!

 

For an experimental approach, see Andrew’s answer.

 

Mike

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Thursday, August 10, 2017 11:08 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] How to figure out the stack size for a thread?

 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 


Re: How to figure out the stack size for a thread?

Michael Rosen
 

Jun,

 

You can use CONFIG_STACK_USAGE to have the build system generate the .su files which summarize the stack usage (if computable at compile time) of all the functions in all the files. You can use this information to determine the max stack height a thread can reach so long as you know the deepest call path (and what functions are a part of it) but summing all of the static usages. I don’t know of an automated way to do this, but if someone else knows, please chime in!

 

For an experimental approach, see Andrew’s answer.

 

Mike

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Thursday, August 10, 2017 11:08 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] How to figure out the stack size for a thread?

 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 


Re: How to figure out the stack size for a thread?

Boie, Andrew P
 

Enable CONFIG_INIT_STACKS.

Use STACK_ANALYZE() from include/misc/stack.h to see how much of your thread stack has been used, that should help you to tune the size value.

 

HTH,

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Thursday, August 10, 2017 11:08 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] How to figure out the stack size for a thread?

 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 


How to figure out the stack size for a thread?

Li, Jun R
 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 


Re: Link error "undefined reference to `__heap_sentry'"

Boie, Andrew P
 

Thank you for the patch.

 

The test case tests/kernel/test_build should have caught this in its newlib configuration, but the build passes in that scenario. I'm looking into why this is the case.

 

Andrew

 

From: Aska Wu [mailto:aska.wu@...]
Sent: Thursday, August 10, 2017 12:42 AM
To: Boie, Andrew P <andrew.p.boie@...>; Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Andrew,

 

Thanks for the information. It turns out an typo in the xtensa linker.ld. newlib references "__heap_sentry" but "_heap_sentry" is defined in the linker script. I've created a PR #1072 for this. But I just found that all linker scripts under arch/xtensa/soc have the same problem. I will update my PR.

 

Regards

 

Aska Wu

 

On Thu, 10 Aug 2017 at 12:39 Boie, Andrew P <andrew.p.boie@...> wrote:

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
Best Regards,
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: Link error "undefined reference to `__heap_sentry'"

aska.wu
 

Andrew,

Thanks for the information. It turns out an typo in the xtensa linker.ld. newlib references "__heap_sentry" but "_heap_sentry" is defined in the linker script. I've created a PR #1072 for this. But I just found that all linker scripts under arch/xtensa/soc have the same problem. I will update my PR.

Regards

Aska Wu

On Thu, 10 Aug 2017 at 12:39 Boie, Andrew P <andrew.p.boie@...> wrote:

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
Best Regards,
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: Link error "undefined reference to `__heap_sentry'"

Boie, Andrew P
 

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
Best Regards,
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: Link error "undefined reference to `__heap_sentry'"

aska.wu
 

Paul,

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

Regards.

Aska

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:
Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
Best Regards,
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: info about device tree for stm32f412zg

Andy Gross
 

On 9 August 2017 at 11:01, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
Fo the nucleo_f412zg there is the file

zephyr/dts/arm/nucleo_f412zg.dts

that includes st/stm32f412.dtsi and then
#include <st/stm32f412-pinctrl.dtsi>
#include <st/stm32f411.dtsi>

stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi

file stm32f4-pinctrl.dtsi contains

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_c: usart2@2 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};

and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};

because chip has only those two mux for USART2.

In the compiled dts there is also usart2_pins_c that it doen't actually
exist in the chip, how to remove it?
So if there are pin differences between the two, then anything non
generic needs to be removed from the .dtsi and put inside a more
specific .dtsi file that is included. The intent of the definitions
was to allow reuse and make it easier to choose things without having
to consult the manual.

The pins_c should only be appearing if it is defined and someone is using it.


the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So
why it contains a specific multiplexing for the usart that has to be
overridden by specific pinmux files?
If the f412 has differences in pinmuxing from the f4, then those
things needs to be separated out. The entries in the -pinctrl.dtsi
are used in the actual nodes in the board specific files. Just
because something is defined does not mean that it is used unless
there is a pinctrl-0/pinctrl-1/pinctrl-2 property in the node that
uses one of the definitions.


info about device tree for stm32f412zg

Massimiliano Cialdi
 

Fo the nucleo_f412zg there is the file

zephyr/dts/arm/nucleo_f412zg.dts

that includes st/stm32f412.dtsi and then
#include <st/stm32f412-pinctrl.dtsi>
#include <st/stm32f411.dtsi>

stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi

file stm32f4-pinctrl.dtsi contains

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_c: usart2@2 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};

and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};

because chip has only those two mux for USART2.

In the compiled dts there is also usart2_pins_c that it doen't actually exist in the chip, how to remove it?

the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So why it contains a specific multiplexing for the usart that has to be overridden by specific pinmux files?

best regards
Max


Re: info about device tree entry for STM32 micros

Andy Gross
 

On 8 August 2017 at 10:52, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
this make sense (but the address of RCC_APB1RSTR is 0x20)

But this raises the question: where is it defined STM32_CLOCK_BUS_APB1 and
how?

Grepping the entire zephyr source I find:

#define STM32_CLOCK_BUS_APB1 2

in file zephyr/include/dt-bindings/clock/stm32_clock.h

that is not 0x20 as I expect
Looking at the drivers/clock_control/stm32_ll_clock.c, they use switch
statements to steer the programming for the clock enables. The actual
call makes a macro/function call to set the enable bit. So in this
case, the device tree denotes the switch value to use and the bit
mask.

I was assuming they were using the offsets. that isn't the case.
they are using ext hal code selected via the switch.

Sorry bout that.

Andy

5321 - 5340 of 8521