ChibiOS Free Embedded RTOS

I tried GCC 6.3.1 (from developer.arm.com)
It makes the exact same code with enabled optimizations


08001fe0 <VectorBC>&#58;
OSAL_IRQ_HANDLER(STM32_USB1_LP_HANDLER) {
8001fe0&#58; b5f0 push {r4, r5, r6, r7, lr}
8001fe2&#58; 46de mov lr, fp
8001fe4&#58; 4657 mov r7, sl
8001fe6&#58; 464e mov r6 ...

I figured it out.
on cortex-m0 PORT_IRQ_PROLOGE saves the LR register, which is then supplied to PORT_IRQ_EPILOGUE


#define PORT_IRQ_PROLOGUE() \
regarm_t _saved_lr = (regarm_t)__builtin_return_address(0)

#define PORT_IRQ_EPILOGUE() _port_irq_epilogue(_saved_lr)


when optimization disabled gcc ...

as I expected, the function ST_HANDLER is incorrectly optimized. Unfortunately, gcc does not allow switching the optimization inside the function.
going to deeply learn ARM assembler

disabling of optimization for the os/hal/ports/STM32/LLD/TIMv1/hal_st_lld.c seems to have completely solved the problem.

hmm... faisal, I don't know where is this strategic location. empty readylist is normal situation, but chSchDoReschedule() call should be blocked by chSchIsPreemptionRequired ...

arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for ...

yes, it seems to USB-related, but the chThdSleepMillisecond() also has an impact
for example, this code works fine

while (true)
{
uint8_t rxbyte = streamGet(&SDU1);
}

moreover, commands are correctly received and sent over USB-serial.
more complex code works fine (with SPI and PWM blocks ...

yes, the USB connected to host.
I just checked, without connection (power only), the system works for a long time

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 ...

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 ...

the code is the simplest now

#include "ch&#46;h"
#include "hal&#46;h"
#include "usbcfg&#46;h"

int main(void)
{
halInit();
chSysInit();

sduObjectInit(&SDU1);
sduStart(&SDU1, &serusbcfg);

usbDisconnectBus(serusbcfg&#46;usbp);
chThdSleepMilliseconds(1000);
usbStart(serusbcfg&#46;usbp ...