ChibiOS Free Embedded RTOS

Hi,

Under certain circumstances ibqReadTimeout fails when called with a TIME_INFINITE interval.

On line 368 in hal_buffers.c the deadline gets calculated regardless if it's used later. If the size of systime_t and interval_t are different this triggers a chDbgCheck in chTimeAddX.

Recommendation ...

Hi,

I'm using 16bit system time, because the chip only has 16bit timers.

It is my intuition that when the system time type and the interval type are different there are some strange corner cases which might fail (int overflow maybe?). But I have no hard evidence yet.

best regards,
greb

Hi,

I found out where the problem was, but not exactly why. By reducing the CH_CFG_INTERVALS_SIZE from 32 to 16 bit the problem disappered. The reason why I did it was to circumvent a failing debug-assert in chTimeAddX when the interval was set to TIME_INFINITE. This solved not only my other ...

Hi,

Thanks for the reply. According to the mcuconfig.h the IRQ priorities seem to look fine (e.g. STM32_ST_IRQ_PRIORITY=8).

I looked into the HAL ST code of ChibiOS and I didn't find any major changes between 16.x and 18.x. I'm somewhat perplexed. The HW runs 16.x without a problem.

best regards ...

Hi,

I'm in the process to port one of my projects from ChibiOS 16.x to 18.x. I've enabled the debugging runtime-checks to hunt down possible bugs in my code base. Unfortunatly, whenever a thread sleeps it triggers SV#8 in the systick timer ISR.

Changing the timer or its IRQ priority doesn't help ...

Hi,

I've found a macro expansion bug in the SPI driver while porting my application to ChibiOS 18.2.x. While using spiSelectI I got the following compiler error:


/disk/greb/src/ChibiOS/os/hal/include/hal_spi.h:160:20: error: invalid type argument of '->' (have 'SPIDriver {aka ...

Hi,

I'm currently debugging a strange instruction fetch problem that occurs on some F103 chips. I'm running the SYSCLK at 48 MHz. According to reference manual (chapter 3.3.3) I should use a wait state of 0x1, but instead FLASH->ACR has a wait state of 0x0. After some digging around in the HAL ...

Hi,

I noticed that there is no HAL support to enable the LSE bypass for STM32F1xx. It works the same as in some other STM32 chips (i.e. setting the LSEBYP bit in the backup domain control register). Other ports (e.g. STM32F0xx) support it by using the STM32_LSE_BYPASS macro. But not STM32F1xx.

I ...

Thank you for your answer. But I think there's a misunderstanding. The problem isn't that the macros are missing, because they're clearly there. And I'm using them already for other boards.

It is the missing definition for the type stm32_gpio_t in os/hal/ports/STM32/LLD/GPIOv1/pal_lld.h which is ...

I've tried to use PAL_LINE and associated macros on a STM32F103. Compiling fails due to stm32_gpio_t's definition is missing from GPIOv1's pal_lld.h
On devices which use GPIOv2 (e.g. STM32L152) it works without problems.
I'm using git branch stable_16.1.x

What are some possible solutions to enable ...