Date   

Zephyr SDK 0.9.1-rc

Nashif, Anas
 

Hi,

We have just posted 0.9.1-rc of the Zephyr SDK. The major changes since the last release bring support for building the Xtensa architecture using GCC and support for running Zephyr inside Qemu. So now you will be able to build Xtensa binaries and run them in Qemu the same way we do things for other architectures.

 

Download the RC from here:

 

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.1-rc1

 

 

Anas


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

If we rely on stm32cube SDK, compilation switch "STM32F103x8" was not created because STM32F103xB was enough
to specify both
STM32F103x8 and STM32F103xB from software point of view.
One difference obviously remains, which is memory footprints, and this is taken care of by Zephyr config system (device tree and mem.h)




On 17 May 2017 at 11:47, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks, I did notice that. Infact that's the reason I ORed it to existing headder. But was unsure since none of the existing includes had a anything ORed with them.

Perhaps, we should OR all macros that uses the same header upfront so as to avoid such confusions?

diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
index 333095b..be905b1 100644 
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
@@ -127,33 +127,33 @@ 
* @{ 
*/ 

-#if defined(STM32F100xB) 
+#if defined(STM32F100xB) || defined(STM32F100x4) || 
defined(STM32F100x6) || defined (STM32F100x8) 
#include "stm32f100xb.h" 
-#elif defined(STM32F100xE) 
+#elif defined(STM32F100xE) || defined(STM32F100xC) || defined(STM32F100xD) 
#include "stm32f100xe.h" 
-#elif defined(STM32F101x6) 
+#elif defined(STM32F101x6) || defined(STM32F101x4) 
#include "stm32f101x6.h" 
-#elif defined(STM32F101xB) 
+#elif defined(STM32F101xB) || defined(STM32F101x8) 
#include "stm32f101xb.h" 
-#elif defined(STM32F101xE) 
+#elif defined(STM32F101xE) || defined(STM32F101xC) || defined(STM32F101xD) 
#include "stm32f101xe.h" 
-#elif defined(STM32F101xG) 
+#elif defined(STM32F101xG) || defined(STM32F101xF) 
#include "stm32f101xg.h" 
-#elif defined(STM32F102x6) 
+#elif defined(STM32F102x6) || defined(STM32F102x4) 
#include "stm32f102x6.h" 
-#elif defined(STM32F102xB) 
+#elif defined(STM32F102xB) || defined(STM32F102x8) 
#include "stm32f102xb.h" 
-#elif defined(STM32F103x6) 
+#elif defined(STM32F103x6) || defined(STM32F103x4) 
#include "stm32f103x6.h" 
-#elif defined(STM32F103xB) 
+#elif defined(STM32F103xB) || defined(STM32F103x8) 
#include "stm32f103xb.h" 
-#elif defined(STM32F103xE) 
+#elif defined(STM32F103xE) || defined(STM32F103xC) || defined(STM32F103xD) 
#include "stm32f103xe.h" 
-#elif defined(STM32F103xG) 
+#elif defined(STM32F103xG) || defined(STM32F103xF) 
#include "stm32f103xg.h" 
-#elif defined(STM32F105xC) 
+#elif defined(STM32F105xC) || defined(STM32F105x8) || defined(STM32F105xB) 
#include "stm32f105xc.h" 
-#elif defined(STM32F107xC) 
+#elif defined(STM32F107xC) || defined(STM32F107xB) 
#include "stm32f107xc.h" 
#else 
#error "Please select first the target STM32F1xx device used in your 
application (in stm32f1xx.h file)" 


Siddharth.


---- On Wed, 17 May 2017 14:20:52 +0530 erwan.gouriou@... wrote ----


According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h,
you should use STM32F103xB:
  /* #define STM32F103xB  */   /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, STM32F103TB and STM32F103VB */

Erwan

On 17 May 2017 at 09:21, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list







Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 17/05/17 13:19, Neil Armstrong wrote:
On 05/17/2017 11:39 AM, Daniel Thompson wrote:
On 15/05/17 17:37, Daniel Thompson wrote:
On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!
Yes!

It solves the problem in the sense that devices are now enumerating correctly! However I'm afraid that the code isn't really robust enough for me to contemplate a pull request at this point (even with ModemManager disabled I am only getting a couple of characters from samples/subsys/usb/console).

I'll try to keep a rebase branch working on my github for anyone interested (branch has Christer's patch, 96b_carbon support and modifications in samples/subsys/usb to allow some of the examples to build):
https://github.com/daniel-thompson/zephyr/tree/hacking/carbon-usb
Hi Daniel,
Thanks for the branch, I'll eventually experiment it on the L4 boards aswell.
But, these STM32 SoCs embeds all the same Synopsys IP, except FS one uses a register to power up the internal PHY.
The STMF4/F7 now runs Linux using the classic DWC2 driver, so it could be the same on Zephyr.
Had someone already tried this ?
As it happens this is the other reason that I'm reluctant to make a pull request of the current code base.

I've not heard of anyone getting the existing DW driver working on STM32. I certainly agree that it would be good to experiment with the native driver.

However, at present my devices of interest are STM32F0x2 parts. These do not have a DWC2 controller but do share similar HAL interfaces with the F4 series. For that reason I won't be putting much priority on native-mode driver work for STM32F4.


Following question: What about Host support ?
AFAIK Zephyr does not currently have any USB host support.


Daniel.


Re: STM32F4: Correct translation from native to LL clock driver

Neil Armstrong
 

On 05/17/2017 11:39 AM, Daniel Thompson wrote:
On 15/05/17 17:37, Daniel Thompson wrote:
On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!
Yes!

It solves the problem in the sense that devices are now enumerating correctly! However I'm afraid that the code isn't really robust enough for me to contemplate a pull request at this point (even with ModemManager disabled I am only getting a couple of characters from samples/subsys/usb/console).

I'll try to keep a rebase branch working on my github for anyone interested (branch has Christer's patch, 96b_carbon support and modifications in samples/subsys/usb to allow some of the examples to build):
https://github.com/daniel-thompson/zephyr/tree/hacking/carbon-usb
Hi Daniel,

Thanks for the branch, I'll eventually experiment it on the L4 boards aswell.

But, these STM32 SoCs embeds all the same Synopsys IP, except FS one uses a register to power up the internal PHY.

The STMF4/F7 now runs Linux using the classic DWC2 driver, so it could be the same on Zephyr.
Had someone already tried this ?

Following question: What about Host support ?

Neil


Daniel.


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>> wrote:

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.

Can you offer any clues?


Daniel.

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


Zephyr Board for USB Webcam!

Kevin Stöckl <k_stoeckl@...>
 

Hello,

I want to build my own "Security Camera" with Zephyr. For that I am looking for the right board to interact with my USB Webcam. Which board will be the best for such an application?


Thanks, Kevin


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran
 

Hi Erwan,

Thanks, I did notice that. Infact that's the reason I ORed it to existing headder. But was unsure since none of the existing includes had a anything ORed with them.

Perhaps, we should OR all macros that uses the same header upfront so as to avoid such confusions?

diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
index 333095b..be905b1 100644 
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
@@ -127,33 +127,33 @@ 
* @{ 
*/ 

-#if defined(STM32F100xB) 
+#if defined(STM32F100xB) || defined(STM32F100x4) || 
defined(STM32F100x6) || defined (STM32F100x8) 
#include "stm32f100xb.h" 
-#elif defined(STM32F100xE) 
+#elif defined(STM32F100xE) || defined(STM32F100xC) || defined(STM32F100xD) 
#include "stm32f100xe.h" 
-#elif defined(STM32F101x6) 
+#elif defined(STM32F101x6) || defined(STM32F101x4) 
#include "stm32f101x6.h" 
-#elif defined(STM32F101xB) 
+#elif defined(STM32F101xB) || defined(STM32F101x8) 
#include "stm32f101xb.h" 
-#elif defined(STM32F101xE) 
+#elif defined(STM32F101xE) || defined(STM32F101xC) || defined(STM32F101xD) 
#include "stm32f101xe.h" 
-#elif defined(STM32F101xG) 
+#elif defined(STM32F101xG) || defined(STM32F101xF) 
#include "stm32f101xg.h" 
-#elif defined(STM32F102x6) 
+#elif defined(STM32F102x6) || defined(STM32F102x4) 
#include "stm32f102x6.h" 
-#elif defined(STM32F102xB) 
+#elif defined(STM32F102xB) || defined(STM32F102x8) 
#include "stm32f102xb.h" 
-#elif defined(STM32F103x6) 
+#elif defined(STM32F103x6) || defined(STM32F103x4) 
#include "stm32f103x6.h" 
-#elif defined(STM32F103xB) 
+#elif defined(STM32F103xB) || defined(STM32F103x8) 
#include "stm32f103xb.h" 
-#elif defined(STM32F103xE) 
+#elif defined(STM32F103xE) || defined(STM32F103xC) || defined(STM32F103xD) 
#include "stm32f103xe.h" 
-#elif defined(STM32F103xG) 
+#elif defined(STM32F103xG) || defined(STM32F103xF) 
#include "stm32f103xg.h" 
-#elif defined(STM32F105xC) 
+#elif defined(STM32F105xC) || defined(STM32F105x8) || defined(STM32F105xB) 
#include "stm32f105xc.h" 
-#elif defined(STM32F107xC) 
+#elif defined(STM32F107xC) || defined(STM32F107xB) 
#include "stm32f107xc.h" 
#else 
#error "Please select first the target STM32F1xx device used in your 
application (in stm32f1xx.h file)" 


Siddharth.


---- On Wed, 17 May 2017 14:20:52 +0530 erwan.gouriou@... wrote ----

According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h,
you should use STM32F103xB:
  /* #define STM32F103xB  */   /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, STM32F103TB and STM32F103VB */

Erwan

On 17 May 2017 at 09:21, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list






Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 15/05/17 17:37, Daniel Thompson wrote:
On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).
I will get back to you as soon as I can!
Yes!

It solves the problem in the sense that devices are now enumerating correctly! However I'm afraid that the code isn't really robust enough for me to contemplate a pull request at this point (even with ModemManager disabled I am only getting a couple of characters from samples/subsys/usb/console).

I'll try to keep a rebase branch working on my github for anyone interested (branch has Christer's patch, 96b_carbon support and modifications in samples/subsys/usb to allow some of the examples to build):
https://github.com/daniel-thompson/zephyr/tree/hacking/carbon-usb


Daniel.


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>> wrote:

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.

Can you offer any clues?


Daniel.


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h,
you should use STM32F103xB:
  /* #define STM32F103xB  */   /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, STM32F103TB and STM32F103VB */

Erwan

On 17 May 2017 at 09:21, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list





Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list




Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran
 

Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list



Re: Reading Values From not supported sensors

Marti Bolivar <marti.bolivar@...>
 

+list

Please remember to keep the list in CC.

On May 16, 2017 1:00 PM, "Marti Bolivar" <marti.bolivar@...> wrote:
Hi Kevin,

Your temperature sensor needs a Zephyr driver to work with the sensor subsystem, yes. If your sensor is not supported right now, you may be able to write a driver for it and submit it for merging upstream, using existing drivers as examples.

Marti

On May 16, 2017 12:11 PM, "Kevin Stöckl" <k_stoeckl@...> wrote:

But is this only possible with the supported sensors (mcp9808,...) or can i take every temperature sensor?




Von: Marti Bolivar <marti.bolivar@...>
Gesendet: Dienstag, 16. Mai 2017 17:02
An: Kevin Stöckl
Cc: zephyr-devel@...ct.org
Betreff: Re: [Zephyr-devel] Reading Values From not supported sensors
 
Hi Kevin,

Temperature sensor support is working in Zephyr. You can search the samples/ directory for the string "SENSOR_CHAN_TEMP" to find example code which reads temperature sensors:

https://github.com/zephyrproject-rtos/zephyr/search?q=SENSOR_CHAN_TEMP&type=

Hope this helps,
Marti


On 16 May 2017 at 07:25, Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


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



Representing Sensor Values with Arduino DUE

Kevin Stöckl <k_stoeckl@...>
 

Hello,


I want to represent my sensor values which are collected with the Arduino DUE in the web over WiFi. For Example in thingsboard.io.
How is it possible to realize this?

Thanks in Advance

Kevin


Re: Reading Values From not supported sensors

Marti Bolivar <marti.bolivar@...>
 

Hi Kevin,

Temperature sensor support is working in Zephyr. You can search the samples/ directory for the string "SENSOR_CHAN_TEMP" to find example code which reads temperature sensors:

https://github.com/zephyrproject-rtos/zephyr/search?q=SENSOR_CHAN_TEMP&type=

Hope this helps,
Marti


On 16 May 2017 at 07:25, Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


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



Reading Values From not supported sensors

Kevin Stöckl <k_stoeckl@...>
 

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,
I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.
I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182
Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!


Daniel.



On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>> wrote:
Hi Erwan
I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.
I'm having a problem with the new LL clock code.
I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:
diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};
clock_control_on(clk, (clock_control_subsys_t *)&pclken);
Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?
I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).
Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.
Can you offer any clues?
Daniel.


BSD Sockets like API: prototyping report #4

Paul Sokolovsky
 

Hello,

Given that initial prototyping was complete and issues were identified
and at least workarounds exist, I started process of refactoring the
code into the in-tree subsystem:
https://github.com/zephyrproject-rtos/zephyr/pull/153 . This is not
targeted for 1.8, but rather for 1.9 window, so feel free to skip for
now if you're busy with 1.8 release work.

I also posted instructions to build the prototype version in the
MicroPython codebase:
https://github.com/pfalcon/micropython/wiki/ZephyrSocket

--
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: STM32F4: Correct translation from native to LL clock driver

Erwan Gouriou
 

Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue

Erwan


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@...> wrote:
Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
 static int usb_dc_stm_clock_enable(void)
 {
        struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
-       struct stm32f4x_pclken pclken = {
-               .bus = STM32F4X_CLOCK_BUS_AHB2,
-               .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+       struct stm32_pclken pclken = {
+               .bus = STM32_CLOCK_BUS_AHB2,
+               .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
        };

        clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work. Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate (there is no attempt to hotplug... if the USB clock rate were wrong hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a bisect to try and chase thise problem down. bisect took me straight to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know this is strictly related to the clock driver change rather than any other zephyr changes.

Can you offer any clues?


Daniel.


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

Hello Siddharth,

It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c

Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).

Regarding upstream; yes, we'll be please to have this board supported!

Erwan




On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:
Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

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



Representing Sensor Values with Arduino DUE

Kevin Stöckl <k_stoeckl@...>
 

Hello,


I want to represent my sensor values which are collected with the Arduino DUE in the web over WiFi. For Example in thingsboard.io.
How is it possible to realize this?

Thanks in Advance

Kevin


Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran
 

Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

5261 - 5280 of 8192