misterhw / bsics-svr Goto Github PK

At commit 4a7f4ec ,

• scpi server task uses iprintf() and consequently HAL_UART_Transmit() for debug output
• default task periodically issues HAL_I2C_Master_Transmit() and HAL_I2C_Mem_Write()

Even the UART messages

iprintf("***Connection closed\r\n");
printf("***Control Connection closed\r\n");

are sufficient to cause I2C1 and eventually I2C2 to lock up with clock (and occasionally SDA due to true slave device lock-up) stuck low:

The last bits exchanged are always part of a full byte + ACK and mostly observed during the long HAL_I2C_Mem_Write() to update SSD1306.

Overall, the periodic timing is much more stretched out as I2C1 and I2C2 comms are interleaved:

I2C_RequestMemoryWrite()

The timeout value passed is equivalent to 25 ms. Extending timeouts to 250 ms does not fix the issue.

HAL I2C functions do not seem to fail gracefully, transmissions are not completed and I2C bus functionality is not recovered.

Ideal solution: interrupt or DMA-based handling of UART transfers (see https://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/). Currently no received characters are being processed, so UART does not need to block program execution at all.