Hi, ppl.
I'm writing a small program for MCU STM32F070 and encountered a strange behavior of the scheduler.
There are two threads in the program - main & idle, the latest commit of OS used, compiled with gcc 7.3.1
Some time after reset chSchDoReschedule is called (from _port_switch_from_isr) with an empty readylist and switches process flow to nowhere, because empty readylist points to itself.
This happens quite quickly when I call chThdSleepMilliseconds intensively.
This same code compiled for F103 works great.
I'm trying to understand, but for now I can't find a reason.
strange behavior of the scheduler on STM32F070 Topic is solved
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: strange behavior of the scheduler on STM32F070
Hi,
Are debug options in chconf.h enabled? state checker and assertions.
Giovanni
Are debug options in chconf.h enabled? state checker and assertions.
Giovanni
Re: strange behavior of the scheduler on STM32F070
all checks are enabled, but none hit
i caught it by inserting to chSchDoReschedule
forgot to mention, Chibios/RT used
Code: Select all
#define CH_DBG_SYSTEM_STATE_CHECK TRUE
#define CH_DBG_ENABLE_CHECKS TRUE
#define CH_DBG_ENABLE_ASSERTS TRUE
#define CH_DBG_ENABLE_STACK_CHECK TRUE
#define CH_DBG_FILL_THREADS TRUE
i caught it by inserting to chSchDoReschedule
Code: Select all
void chSchDoReschedule(void) {
thread_t *otp = currp;
/* Picks the first thread from the ready queue and makes it current.*/
currp = queue_fifo_remove(&ch.rlist.queue);
if( currp == (thread_t *)&ch.rlist.queue ) __asm("BKPT #0\n") ; // Break into the debugger
forgot to mention, Chibios/RT used
Re: strange behavior of the scheduler on STM32F070
everything becomes even more interesting
chSchIsPreemptionRequired should return false if readylist empty.
I inserted a bpt in _port_irq_epilogue
it does not hit, but chSchDoReschedule() still called from _port_switch_from_isr() with an empty readylist...
how does it get there?
chSchIsPreemptionRequired should return false if readylist empty.
I inserted a bpt in _port_irq_epilogue
Code: Select all
if (chSchIsPreemptionRequired()) {
if( ch.rlist.queue.next == (thread_t *)&ch.rlist.queue ) __asm("BKPT #0\n") ; // Break into the debugger
/* Preemption is required we need to enforce a context switch.*/
ctxp->pc = (regarm_t)_port_switch_from_isr;
}
it does not hit, but chSchDoReschedule() still called from _port_switch_from_isr() with an empty readylist...
how does it get there?
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: strange behavior of the scheduler on STM32F070
the code is the simplest now
it crashes after 10-15 seconds
MCU STM32F070F6, chconf - all subsystems disabled, halconf - usb-serial enabled only, gcc 7.3.1 from developer.arm.com
usbcfg.c and usbcfg.h - default
keep researching the problem
Code: Select all
#include "ch.h"
#include "hal.h"
#include "usbcfg.h"
int main(void)
{
halInit();
chSysInit();
sduObjectInit(&SDU1);
sduStart(&SDU1, &serusbcfg);
usbDisconnectBus(serusbcfg.usbp);
chThdSleepMilliseconds(1000);
usbStart(serusbcfg.usbp, &usbcfg);
usbConnectBus(serusbcfg.usbp);
while (true)
{
chThdSleepMilliseconds(2);
}
}
it crashes after 10-15 seconds
MCU STM32F070F6, chconf - all subsystems disabled, halconf - usb-serial enabled only, gcc 7.3.1 from developer.arm.com
usbcfg.c and usbcfg.h - default
keep researching the problem
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: strange behavior of the scheduler on STM32F070
Hi,
Try increasing the stack size in makefile.
Giovanni
Try increasing the stack size in makefile.
Giovanni
Re: strange behavior of the scheduler on STM32F070
this is the first thing I thought. unfortunately, increasing the size of the stacks does not solve the problem.
I have the CH_DBG_FILL_THREADS option enabled for determining the use of the stacks.
main and process stacks uses approx 160 bytes, idle thread seems to not use the stack at all.
situation is not like stack overflow
another interesting observation: if simply exit from chSchDoReschedule with an empty list, then everything is working correctly. This means that the internal structures of the OS are not destroyed. need to find how control gets here bypassing conditions, but unfortunately, cortex-m0 does not have tracing engine
I have the CH_DBG_FILL_THREADS option enabled for determining the use of the stacks.
main and process stacks uses approx 160 bytes, idle thread seems to not use the stack at all.
situation is not like stack overflow
another interesting observation: if simply exit from chSchDoReschedule with an empty list, then everything is working correctly. This means that the internal structures of the OS are not destroyed. need to find how control gets here bypassing conditions, but unfortunately, cortex-m0 does not have tracing engine
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: strange behavior of the scheduler on STM32F070
Hi,
Does the delay in chThdSleepMillisecond() affect the problem?
Does removing the USB code affect the problem?
Which compiler distribution are you using? (not just version)
Are you using startup files provided with ChibiOS or something else?
Giovanni
Does the delay in chThdSleepMillisecond() affect the problem?
Does removing the USB code affect the problem?
Which compiler distribution are you using? (not just version)
Are you using startup files provided with ChibiOS or something else?
Giovanni
Re: strange behavior of the scheduler on STM32F070
as I understand, the delay does not affect the problem. the system crashes after a random time, but within 30 seconds.
removing the USB code fixes the problem, but in this case there is no any computing at all.
To create interrupt load, I connected a pwm module with rate of 10khz, but everything works fine.
I use gcc-arm-none-eabi-7-2018-q2-update-win32 from developer.arm.com (https://developer.arm.com/open-source/g ... /downloads)
startup files and linking script are default provided with ChibiOS.
removing the USB code fixes the problem, but in this case there is no any computing at all.
To create interrupt load, I connected a pwm module with rate of 10khz, but everything works fine.
I use gcc-arm-none-eabi-7-2018-q2-update-win32 from developer.arm.com (https://developer.arm.com/open-source/g ... /downloads)
startup files and linking script are default provided with ChibiOS.
Who is online
Users browsing this forum: No registered users and 55 guests