ChibiOS Free Embedded RTOS

If I had to guess, that means the bug isn't exactly "simplex TX followed by DMA RX" but is actually something like "any operation without RX MINC set, followed by an operation with RX MINC set"

The unmodified SPI MMC driver runs in to this on H7. Here's the github issue where I debugged it and followed it back to the errata sheet: https://github.com/rusefi/rusefi/issues ... -785337711

We do it there before a send as well, but I'm pretty sure it's only required before receive or exchange (and should get moved to the spi lld).

In os/hal/ports/STM32/LLD/ADCv4/hal_adc_lld.c, if you have dual mode ADC1/2 enabled, and also ADC3 enabled, the code starting on line 807 (adcp->adcm->CFGR2 = grpp->cfgr2; etc) stomps over the master ADC configuration set in lines 765-780. It's missing an else case there and just runs ...

Works for me now, thanks!

Hi, I'm running off of pretty close to master on GitHub, and I'm hitting this assertion: m (I'm not doing anything unusual, it's a normal statically allocated thread I'm trying to start). STM32F0, so armv6m.

stktop gets aligned on PORT_NATURAL_ALIGN (4), but then we check that it's aligned to PORT ...

And another one: If you define CH_CFG_USE_REGISTRY but not CH_DBG_ENABLE_STACK_CHECK, then chRegFindThreadByWorkingArea is a missing symbol.

Latest ChibiOS from GitHub doesn't build if CH_CFG_USE_REGISTRY is false. See near the end of chthreads.c function chThdObjectInit, there's a line that says

(void)name;

But there's no longer a parameter called name!

Does this reproduce on an STM32H7? It uses a different USB IP and driver.

That does look better. I think the exact bug before was that if you managed to exactly catch a subsecond rollover (ie, oldssr != ssr on the first iteration), then you had to wait a full second for it to "come back around".

Is it guaranteed that we need a loop, instead of the if originally proposed ...