Using firmware with STMF103C6

Firmware
1

Hi all,

I’m trying to get the firmware to run on one of my own boards that has a STM32F103C6 chip on there. Compiling the firmware was quite easy, thanks to the documentation in the repo. Now the board isn’t much spark-like, so I undefined the SPARK_WLAN_ENABLE, SPARK_SFLASH_ENABLE and SPARK_RTC_ENABLE defines and I changed the application.cpp to be pretty much a blinky sketch.

I built the firmware using the USE_SWD_JTAG and DEBUG_BUILD options and tried debugging the firmware using Eclipse with GDB. This seems to work fine: I can see the program starting in the Reset_Handler:… I set some breakpoints set after that, so I can see it running towards the bl SystemInit etc. Now this is where it’s starting to act funny.

According to DGB, it steps towards the bl SystemInit, but then just steems to step “over” it. By which I mean that I see branch instruction highlighted, but never executed. On closes inspection, the disassembly shows:

LoopFillZerobss:
08007500:   movs r0, r0
 95       	cmp	r2, r3
08007502:   movs r0, r0
 96       	bcc	FillZerobss
08007504:   lsrs r0, r0, #32
 98       	bl  SystemInit
08007506:   ands r1, r0
08007508:   movs r0, r2
100       	bl  SparkCoreConfig
0800750a:   movs r4, r0
0800750c:   movs r0, r0
102       	bl	CallConstructors
0800750e:   movs r0, r0
08007510:   lsls r7, r7, #3
104       	bl	main
08007512:   lsls r7, r7, #3
08007514:   movs r0, r0
105       	bx	lr    
08007516:   movs r0, r0
 75       	ldr	r3, =_sidata
08007518:   andeq r0, r0, r0
 81       	ldr	r0, =_sdata
0800751c:   andmi r0, r1, r0, lsl #16
 82       	ldr	r3, =_edata
08007520:   andeq r0, r5, r0, lsr #32
 86       	ldr	r2, =_sbss
08007524:   andeq r0, r0, r0
 94       	ldr	r3, = _ebss
08007528:   ldrshteq r0, [pc], #15
118       	b	Infinite_Loop

So does this mean that all branch instructions are in face movs r0, r0?

Can someone point me in the right direction perhaps? I’m clearly overlooking something here…

2

That looks a bit strange - the assembly source and the actual output don’t seem to match up at all. Two possible causes:

  • a parallel universe has merged with ours incompletely
  • the ELF file is the wrong one or out of date.

I’m not sure what do suggest about the first one, But for the second cause, please check to be sure your symbols file (.elf) is the correct one. Getting that wrong will cause this kind of mixup.

Hope that helps! :smile:
Cheers
mat

1 Like
3

Hi Matthew, thank, actually it was quite an easy fix: I had to use the “non-dfu” linker script instead of the linker_stm32f10x_md_dfu.ld one. Now for an entirely different problem: the debugger doesn’t step anymore. Like nothing happens if I press step over. I’ll start a fresh build later.

I’m starting to think I’m approaching this a bit wrong and I should ask different questions. For example: what would be the right way to approach porting the firmware for a different microcontroller? I wouldn’t expect much changes, other than the sizes in the linker file and disabling WIFI and flash support.

4

Great to hear you got it fixed! A clean build might help, also restarting st-link if you are using that.

Which branch are you using to build from? I’m guessing the master branch. fyi, Current development is happening in the “develop” branch so you might want to take a look over there. One key change is that all hardware dependencies have been moved to a Hardware Abstraction Layer.

As to the approach - there are two ways:

  • hack the code, inserting conditional compile statements around any code that you don’t need. This is probably the quickest way but the code won’t be generally usable outside of your project.

  • create a new target platform that is a “pure” STM32103 device. The main work here is refactoring the HAL for the Core to separate the stm32f1xx generic part from the current Core HAL (that includes the cc3000 and SPI flash) which is not part of your platform.

To elaborate more on the 2nd option, we are doing this with the Electron, which shares a lot of the non-networking code in common with the photon since both are based on the same STM32F205 MCU. We are factoring out the sources for a generic stm32f2xx HAL that is shared by all our STM32F2 platforms. The same scheme could work to separate out a common base for your bare STM32F103 and the Core.

I realize that this is probably more work than you were envisaging. Just pointing out the option so you know it’s there!

5

Yeah I’m building from the master branch. I noticed the 0.4.2 tag today and inspected that too, but I chose not to use it for the sake of simplicity. Using a HAL is the way to go forward, but for now I just wanted to get this one working. Also, I noticed the size of the binary is smaller on de master branch and it’s easer to shrink to the 32kb flash that I’ve got.

But without asking for a finished solution, is there any obvious reason firmware won’t run on my device? Like what would be things you’d look at straight away when porting the platform. Any simple pitfalls to avoid?

6

The develop branch supports LTO compile with COMPILE_LTO=y passed to make. This can produce very small executables. Also try adding SPARK_WIFI=n to cut out Wifi and cloud functionality.

The firmware should run once you’ve removed the hardware that’s not present, i.e. the WiFi and Flash, as you mentioned. Nothing else comes to mind right now!

1 Like