strange behavior of the scheduler on STM32F070 Topic is solved

Report here problems in any of ChibiOS components. This forum is NOT for support.
apmorton
Posts: 35
Joined: Fri Sep 29, 2017 10:26 am
Been thanked: 16 times

Re: strange behavior of the scheduler on STM32F070

Postby apmorton » Tue Nov 27, 2018 10:48 pm

Obviously a compiler fix is the best solution, but having gone down this path before with regressions in gcc-arm-none-eabi I would not hold my breath. I am still waiting on some regressions reported and confirmed over a year ago.

A less than great workaround might be to mark the IRQ handler as

Code: Select all

__attribute__((naked))


If you aren't familiar with the attribute, it is mentioned here: https://gcc.gnu.org/onlinedocs/gcc/ARM- ... Attributes

Strictly speaking you can only rely on plain asm statements inside a naked function, so to be on the safe side you would need to declare a separate function that *isn't* naked and move the current function body there - excluding the lr save/restore macros. You can then use inline assembly in the naked function to call your new/real IRQ handler.

If it works it's not the worst hack in the world, and it's better than #error with a bugged compiler version.

gclarkii
Posts: 21
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: strange behavior of the scheduler on STM32F070

Postby gclarkii » Sat Feb 02, 2019 6:33 pm

Also available is to mark the function as
int __attribute__((optimize("O0"))) foo(uint8_t fooin) {
}
OR
#pragma GCC push_options
#pragma GCC optimize ("O0")
CODE
#pragma GCC pop_options

Just a couple of more options

Oh, Giovanni, where is that code for the cortex-M0 located? I'll modify the code to include one of the above and see if my locks still persist.

Never mind, I found the correct file and modified the code as follows:

Code: Select all

#pragma GCC push_options
#pragma GCC optimize ("O0")
#if defined(__GNUC__) || defined(__DOXYGEN__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__builtin_return_address(0)
#elif defined(__ICCARM__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__get_LR()
#elif defined(__CC_ARM)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__return_address()
#endif
#pragma GCC pop_options


With that modification, compiling with -O2 and 230400 I've experienced ZERO locks! :mrgreen:
In over 20,000 cycles!

So the locks on the STM32F030K6/F4 were due to the bug. Still does not explain why the 030CC ran just fine...Arrggghhhh
Giovanni, do you see any down sides to O0 for just that code? It requires no other changes that I can see.

GB
Last edited by gclarkii on Sat Feb 02, 2019 7:10 pm, edited 1 time in total.

User avatar
Giovanni
Site Admin
Posts: 11786
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 503 times
Been thanked: 427 times
Contact:

Re: strange behavior of the scheduler on STM32F070

Postby Giovanni » Sat Feb 02, 2019 6:52 pm

Hi,

The code is located under /os/common/ports/ARMCMx/compilers/chcore_v6m.c

I am familiar with the naked attribute, you would have to do full stacking even for those ISRs not needing it. Removing optimizations is not an option for the same reason, performance. This is also a commercial product anything less than a full solution is not an option.

This is why I am deprecating the faulty compilers.

Giovanni

gclarkii
Posts: 21
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: strange behavior of the scheduler on STM32F070

Postby gclarkii » Sat Feb 02, 2019 7:18 pm

How much of slow down is it really?

Looking the original report of the bug, 5 lines of assembly are added for the O0 level. I don't have clue how that would translate in performance though.

Maybe make it an option via make. I'm willing to bet that the vast majority of people, including the commercial customers, would rather use a new GCC and take the hit. Also, how many of the commercial customers are even running GCC compared to the other compilers?

Turn it off by default and just document it in the demo files for the M0/M0+.
Last edited by gclarkii on Sat Feb 02, 2019 7:24 pm, edited 1 time in total.

User avatar
Giovanni
Site Admin
Posts: 11786
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 503 times
Been thanked: 427 times
Contact:

Re: strange behavior of the scheduler on STM32F070

Postby Giovanni » Sat Feb 02, 2019 7:23 pm

That code is in one of the most critical places and affects interrupts handling.

Giovanni

gclarkii
Posts: 21
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: strange behavior of the scheduler on STM32F070

Postby gclarkii » Sat Feb 02, 2019 7:33 pm

If nothing else, make sure that the bug is noted(Maybe in each demo file/makefile or ???) and how to work around it, both ways.
i.e. use an older GCC or modify the code as follows and note the performance hit. I'm not using ChibiOS as a RTOS, but as a VERY good foundation.
In the areas where I need the performance I'm using M3/M4 cores anyway.

Code: Select all

#if defined(__GNUC__) || defined(__DOXYGEN__)
#pragma GCC push_options
#pragma GCC optimize ("O0")
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__builtin_return_address(0)
  #pragma GCC pop_options
#elif defined(__ICCARM__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__get_LR()
#elif defined(__CC_ARM)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__return_address()
#endif


Ok, I'll shut up now. I just felt that people should be given the choices.... :geek:
(Also confirming to limited degree that the above fixes my problem. There might be side effects that I just don't hit)


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 2 guests