1. devel@lists.zephyrproject.org
  2. Messages
   Date   
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@...> 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@...> 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
Re: info about device tree entry for STM32 micros

Massimiliano Cialdi
 

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


best regards

Max

On 08/08/2017 16:59, Andy Gross wrote:
I am pretty sure the encoding is the following:

<&rcc STM32_CLOCK_BUS_APB1 0x00040000>

First cell is reference to the clock node. That node will have a base
address. The second cell is which RCC register. In this case it is
APB1 (0x1c). Third cell is the mask for the enable bit for USART3.



On 8 August 2017 at 09:15, Kinder, David B <david.b.kinder@...> wrote:
Start here for kernel clocks documentation:
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi
<massimiliano.cialdi@...> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3
element array, but I don't know the meaning of each of them


best regards

Max

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

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
.
Re: info about device tree entry for STM32 micros

Andy Gross
 

I am pretty sure the encoding is the following:

<&rcc STM32_CLOCK_BUS_APB1 0x00040000>

First cell is reference to the clock node. That node will have a base
address. The second cell is which RCC register. In this case it is
APB1 (0x1c). Third cell is the mask for the enable bit for USART3.

On 8 August 2017 at 09:15, Kinder, David B <david.b.kinder@...> wrote:
Start here for kernel clocks documentation:
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi
<massimiliano.cialdi@...> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3
element array, but I don't know the meaning of each of them


best regards

Max

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

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
Re: info about device tree entry for STM32 micros

Kinder, David B <david.b.kinder@...>
 

Start here for kernel clocks documentation: 
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi <massimiliano.cialdi@...> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
   compatible = "st,stm32-usart", "st,stm32-uart";
   reg = <0x40004800 0x400>;
   clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
   interrupts = <39 0>;
   status = "disabled";
   label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3 element array, but I don't know the meaning of each of them


best regards

Max

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
info about device tree entry for STM32 micros

Massimiliano Cialdi
 

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3 element array, but I don't know the meaning of each of them


best regards

Max
Re: Switching debuggers/flashers

Piotr Mienkowski
 

On 08.08.2017 10:57, Erwin Rol wrote:
Is there a standardized way to switch debugger/flash tool ?

The only thing I could find was a config file that uses
OPENOCD_INTERFACE variable to select a debugger.

Is the OPENOCD_INTERFACE variable the correct way to do this? With other
words can I also use that variable in the Olimexino openocd config
file ?
I believe there is no standard way in Zephyr to select debug interface
so far but if you use OPENOCD_INTERFACE environment variable we would
establish a standard, for OpenOCD that is.

In case of existing implementation for sam_e70_xplained board OpenOCD
will look for the appropriate interface configuration in an
interface/$(OPENOCD_INTERFACE).cfg file on its internal search path.
I.e. we should be able to support any debugger/flasher as long as
OpenOCD provides an interface file for it.

To flash via a default interface one would use 'make flash', and for
non-default interface e.g. to select J-Link probe 'make
OPENOCD_INTERFACE=jlink flash'.

You would of course need to modify openocd.cfg to add such support for
olimexino_stm32 board.

- Piotr
Switching debuggers/flashers

Erwin Rol
 

Hello All,

Is there a standardized way to switch debugger/flash tool ?

I want to use the ST-Link2 with the Olimexino board, but I have to
change the openocd.conf file to do so, because the board uses another
debugger by default.

The only thing I could find was a config file that uses
OPENOCD_INTERFACE variable to select a debugger.

Is the OPENOCD_INTERFACE variable the correct way to do this? With other
words can I also use that variable in the Olimexino openocd config
file ?

- Erwin
Re: [devel] How to generate .hex image

Tidy(Chun hua)Jiang <tidyjiang@...>
 

Hi Boie，

Got it, thanks!

2017年1月18日 00:41于 "Boie, Andrew P" <andrew.p.boie@...>写道：

At the moment, you can add these two lines to your soc or arch-level Makefile to get ihex files generated.

A better enhancement would be to control this with Kconfig.

 

zephyr: $(KERNEL_HEX_NAME)

all: $(KERNEL_HEX_NAME)

 

From: Tidy(ChunHua) Jiang [mailto:tidyjiang@...]
Sent: Sunday, January 15, 2017 6:40 PM
To: devel@...
Subject: [devel] How to generate .hex image

 

Hello,

When building, some BOARDs will generate both .bin and .hex, but others only .bin.
Is there a build switch to control this ?

My current stupid method is that, enter the directory where zephyr.elf is located, and then type:
/opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/arm-poky-eabi-objcopy -S -O ihex -R .note -R .comment -R COMMON -R .eh_frame zephyr.elf zephyr.hex

Thanks.

 

 
回复: did zephyr support armcc and fromelf toolchain?

luobaidunpaigu@sina.com <luobaidunpaigu@...>
 

yes, follow the instructions:
Page: https://www.zephyrproject.org/doc/getting_started/getting_started.html
Section: Using Custom and 3rd Party Cross Compilers

OR

https://www.zephyrproject.org/doc/getting_started/getting_started.html#using-custom-and-3rd-party-cross-compilers
 
luobaidunpaigu@...

 
发件人： 曹子龙
发送时间： 2017-08-04 17:54
收件人： zephyr-devel
主题： [Zephyr-devel] did zephyr support armcc and fromelf toolchain?
HI all:

   Did zephyr support armcc and fromelf toolchain present? 


 
Re: Shipable timeout

Erwin Rol
 

On Sat, 2017-08-05 at 13:21 +0000, Kinder, David B wrote:
Might try a PR close/open to give shippable a kick?

-- david kinder

On Aug 5, 2017, at 6:09 AM, Erwin Rol <mailinglists@...> wrote:

Hey all,

my PR caused a shipable timeout;

https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/3031/3/console

What do I do now ?

It seems to have figured out by itself that it has to rerun shipable.

- Erwin
5441 - 5460 of 8632