Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou

Hi Siddharth,

Switch should be created by ext/hal/st/stm32cube/Makefile from CONFIG_SOC flag.
The right way to configure this flag is to define your SoC in arch/arm/soc/st_stm32/stm32f1/Kconfig.defconfig.stm32f103x... files


On 17 May 2017 at 21:21, Siddharth Chandrasekaran <siddharth@...> wrote:
Thanks Erwan, now I understand why the switch was not created. That still leaves us with how and where we have to create those switches to enable the right hearers.

Is there any _nice_ way to achieve this? Ofcourse, I can continue with the current solution of ORing STM32F103x8 alone.


---- On Wed, 17 May 2017 18:44:41 +0530 erwan.gouriou@... wrote ----

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 
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" 
#error "Please select first the target STM32F1xx device used in your 
application (in stm32f1xx.h file)" 


---- 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 */


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.


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 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.


---- 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:
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!

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


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 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.


Zephyr-devel mailing list

Join to automatically receive all group messages.