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

Zephyr-devel@lists.zephyrproject.org

https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel