I found an inconsistent behaviour of my code using I2C code.
The code for a I2C device with the STM32F401 worked fine with the full CPU speed, but when I slowed it down (changing the PLL settings in system.c accordingly), it started hanging on (and eventually timing out on line 48 of I2CMasterPollingFeature::readBytes() inside checkEvent(I2C_EVENT_MASTER_BYTE_RECEIVED). The behaviour was slightly different with "debug" and "fast" builds. It looked like it was a timing issue. During debugging I found, that after receiving the second last byte and after the "if (!count)" was entered, the checkEvent() never returned until the timeout kicked in.
This fix has been tested in all build configurations (debug, fast and small), with both, slow (8MHz) and full CPU speed on both STM32F401 and STM32F411 devices.
I found an inconsistent behaviour of my code using I2C code.
The code for a I2C device with the STM32F401 worked fine with the full CPU speed, but when I slowed it down (changing the PLL settings in system.c accordingly), it started hanging on (and eventually timing out on line 48 of I2CMasterPollingFeature::readBytes() inside checkEvent(I2C_EVENT_MASTER_BYTE_RECEIVED). The behaviour was slightly different with "debug" and "fast" builds. It looked like it was a timing issue. During debugging I found, that after receiving the second last byte and after the "if (!count)" was entered, the checkEvent() never returned until the timeout kicked in.
This fix has been tested in all build configurations (debug, fast and small), with both, slow (8MHz) and full CPU speed on both STM32F401 and STM32F411 devices.