Support for STM32F103 Medium Density Performance Line

[pratipm]

Is there any simple way I can use the library for STM32F103C8 (Medium density Performance line)? Boards with this cpu are available for about $5 on ebay, and I happen to have 2 of them.
Thanks.

-Pratip

[Andy Brown]

Hi and welcome to the forum. It's quite likely that the library will work for you by using the f1hd configuration and simply avoiding the peripherals that you don't have.

The f1hd examples won't work "out of the box" because the linker script is designed for a 512Kb/64Kb configuration. You'd need to adjust it to match the 64Kb/20Kb configuration of your board. Your 72MHz clock matches the HD so the startup code that sets the clocks should work without changes.

[pratipm]

Hi Andy,
Thanks for such a quick response. I'll give it a try right now!

-Pratip

[Kenjutsu]

Hi Andy,
Thanks for such a quick response. I'll give it a try right now!

-Pratip

Have you had any success in getting it to work with the STM32F103C8?

[Andy Brown]

Have you had any success in getting it to work with the STM32F103C8?

Hi, have you tried one of the examples on the F103C8? If you have tried and are having problems then please let me know and I'll try to help.

[Kenjutsu]

Good day,

Not yet. I am still waiting for my board to arrive via eBay 

I will provide feedback as soon as the board arrives, which will probable only be within the next month   

[Kenjutsu]

Well, my F103 board finally arrived  I got this one: STM32F103C8T6 ARM STM32 Minimum System Development Board Module

I followed the tutorial From zero to a C++ STM32 development environment and completed Step 6, selecting the f1_hd_72_8 configuration for stm32plus and stm32plus-examples-blink. On my board the onboard LED is on PC13. So, just to get me started:

• what must I change in blink.cpp for the LED on PC13


• what else must I change to accommodate my F103 board which has 20K RAM and 128K Flash

Thank you 

[Kenjutsu]

I saw this post here on the forum: Blink example on F103 custom board

I modified Linker.ld as follows:

Code Select Expand

_estack = 0x20004FFF;    /* end of $(RAM_LENGTH) RAM */

_Min_Heap_Size = 0;      /* required amount of heap  */
_Min_Stack_Size = 0x200; /* required amount of stack */

MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
}

and blink.cpp as follows:

Code Select Expand

      GpioD<DefaultDigitalOutputFeature<13> > pc;

      // loop forever switching it on and off with a 1 second
      // delay in between each cycle

      for(;;) {

        pc[13].set();
        MillisecondTimer::delay(1000);

        pc[13].reset();
        MillisecondTimer::delay(1000);

I compile and upload to the board, but still nothing happens. I also connected 4 LEDs to PA0, PA1, PA2 and PA3 and modified the code accordingly, but nothing happens 

[Andy Brown]

Those linker settings look OK to me. Assuming you've connected the LED with a series resistor appropriate to the IO voltage on your board (probably 3.3V) then it should flash.

Can you run it in the Eclipse debugger and see what's going on?

[yaqwsx]

Hello,
I am also trying to use your great-looking library for STM32F103C8. I tried to use the F1_HD settings with linker script from VisualGDB. The blink example hangs in Default_Handler. It seems like no handlers were defined - when I look inside the g_pfnVectors, all vectors have defined Default_Handler.

Could you please take a look at it?

[Andy Brown]

Hello,
I am also trying to use your great-looking library for STM32F103C8. I tried to use the F1_HD settings with linker script from VisualGDB. The blink example hangs in Default_Handler. It seems like no handlers were defined - when I look inside the g_pfnVectors, all vectors have defined Default_Handler.

Could you please take a look at it?

I've ordered one of those incredibly cheap STM32F103C8 boards from ebay to have a look at but it's likely to be several weeks before it reaches me.

Can you break in Reset_Handler and single step to find out where it goes wrong? It's assembly language but is quite short. Basically it sets up some data then calls SystemInit and then main. It'll be particularly interesting to see if it gets past SystemInit where the clocks are initialised.

[yaqwsx]

Reset_Handler executes main. Even the pin is set high. However after several cycles in MillisecondTimer::delay the Default_Handler is triggered. It seems to me like the interrupt for SysTick was not defined.

[Andy Brown]

The vector table in the MD series is shorter than the the HD but it is location-compatible right up to the end. Nevertheless, let's try replacing the startup assembly code with one designed for the MD line. Please replace the content of system/f1hd_72_8/Startup.asm with the attached file and let me know if it helps. I'm assuming you've already set the correct values for your flash and SRAM sizes in the linker script.

[yaqwsx]

I looked closely to the startup code and the g_pfnVectors array is initialized properly (there are non-null address where should be), however all of them point to DefaultHandler.

There are also definitions for the aliases in the startup code like this:

Code Select Expand

void SysTick_Handler()            __attribute__ ((weak, alias ("Default_Handler")));

It seems like the aliases doesn't change when the library is linked.

To be clear: I am trying to use your library with GNU toolchain using Visual Studio and VisualGDB plugin, so I setup the project from scratch. It is possible, that I have ommited some steps necessary for the aliases to work. I attach the configuration of the project (the startup code and linker script are generated by VisualGDB).

[Andy Brown]

To be clear: I am trying to use your library with GNU toolchain using Visual Studio and VisualGDB plugin, so I setup the project from scratch. It is possible, that I have ommited some steps necessary for the aliases to work. I attach the configuration of the project (the startup code and linker script are generated by VisualGDB).

This is looking related to the change made in issue 19 where the weak alias from SysTick_Handler to Default_Handler in Startup.asm was removed and now looks like this:

Code Select Expand


/*
* SysTick_Handler in stm32plus is now marked 'weak' so that compatibility with other
* frameworks is made possible.

  .weak  SysTick_Handler
  .thumb_set SysTick_Handler,Default_Handler
*/


The weak alias is now made to the stm32plus implementation so that users of an RTOS can integrate with the library and use the RTOS implementation of SysTick.

All other weak aliases of SysTick_Handler to Default_Handler must be removed. Unfortunately the Startup.asm I attached in my previous post did not have this weak alias commented out. If you could comment it out and ensure there are no more weak aliases for SysTick_Handler in your startup code then you should be OK.