LOCM3 vector table is all blocking-handlers

[AAATom]

I have followed your tutorial an got it to work with simple GPIO and loop-delays.

Then I tried using ISRs and it simply did not work. Everything compiles without a glitch and loads into the target board (BluePill) and runs fine - except no ISRs get invoked. I do get interrupt(s) but they get stuck in blocking handlers.

Looking deeper I found that the whole vector table is filled with only blocking handlers. Here is a disassembly screenshot showing vector table:

It is as though linker simply ignores my nicely defined interrupt handler function(s), e.g.

void sys_tick_handler(void)
{
...
}

void tim1_up_isr(void)
{
...
}

I have checked the function names n-fold and have tried several online examples including those from the libopencm3-examples project to no avail. This looks as a linker issue but I cannot figure it out (probably because I'm new to gcc).

[OliviliK]

Tom, You are ahead of me in this. By inspecting the LOCM3 make files, I did realize that we are missing some functionality in EmBitz to populate the handlers for LOCM3.

In past, I have been using Standard Peripheral Library as the default by EmBlocks/EmBitz. That was working without any issues.

As you have observed, the Wiki has been in hold due to uncertainty of LOCM3 future. I do expect the Unicore-Mx to be an alternative, but it is not yet ready for prime time. The two other alternatives for EB libraries are CubeF1/F4/F7/L4 and ChibiOs/RT/NIL/HAL. As you know, SPL is not available for F7.

[AAATom]

Hi Olavi, thanks for getting back to me.

I have the SPL and even STM32CubeMX ISR code working in EmBitz too. The code from STM32CubeMX initialization code generator worked without touching the files, just had to tweak two options for linker and assembler (apart from setting Build options to be the same as in a project generated by EmBitz for the same MCU. The .l file generated by STM32CubeMX worked just fine.

That makes me wonder what is wrong with the linking process for LOCM3 ...

[FTC11292]

If you look the blog link in the Wiki, there you have a description of the step 4.1, which was not working in my MinGW environment in W10. Perhaps the make file works properly in genuine Linux platform. That step 4.1 handles the interrupt setup process.

I am afraid that I don't have good answers for this.

[AAATom]

I'm running all this on Windows 7 VM (still deciding which environment I'll use) and had no problems with the process. The files look good, even the resulting map file seems to have all the symbols there (I did not go into detailed checking, though). As I said, it looks like a linker issue.

I hoped to get jump-started with STM32F103 development for my (private) side project since I found quite a lot of useful examples using LibOpenCM3. As I haven't managed to get any of them working (apart from simple LED-blinking) I've turned back to good old start-from-scratch way I always handled embedded development. The STM32CubeMX looks the way to go.

Oh, and EmBitz is the only free IDE with debugging that worked out-of-the box so far.

[AAATom]

Seems that the problem is in the "startup_stm32f10x_md.S" file which populates the vector table with symbols that are not tied to C/C++ symbols. For example, the _SysTickHandler symbol is defined in LibOpenCM3's "core_cm3.h" file as #define SysTick_Handler sys_tick_handler but that does not define it for the linker - and linker then uses _SysTickHandler defined by _def_irqhandler macro in the "startup_stm32f10x_md.S" file.

Simply renaming void _sys_tickhandler(void) to void _SysTickHandler(void) solves the problem.

To fix this I added #include (which contains only #define's of IRQ handler alternative names) to "startup_stm32f10xmd.S" file and added another search path to the project options (C:\CommonLibs\libopencm3\include\libopencmsis\stm32\f1) - but I also had to add #define SysTick_Handler sys_tickhandler to make it pass assembly (because it is not defined in "irqhandlers.h" for some reason).

Now it works.

Is this the right way to do it?

[OliviliK]

Tom,

You have done an excellent detective work. Without knowing all the backgrounds, this seems to be the explanation and you have solved the problem. Thanks for sharing your observations.

[AAATom]

You are welcome, Olavi!