Hello, STM32 Developers/STM32 Enthusiasts!
I got a NUCLEO-U5A5ZJ-Q and tried using SPI with GPDMA to drive an SSD1309 OLED display, which works fine without DMA.
On this device we use GPDMA, which is new to me.
I managed to successfully transfer the first 128 bytes using GPDMA, displaying the first page on the OLED screen.
And I saw the interrupts of the half-transfer and full-transfer complete using a logic analyzer, by toggling an IO pin.
Next, I want to send a few command bytes to the OLED display, before sending the next 128 bytes through a DMA transfer. However, the SPI transfer fails after the DMA transfer is completed. I think HAL didn't completely clean up the transfer.
So I'll have to omit using DMA on the STM32U5A5 MCU as it doesn't work well with GPDMA yet.
The problem could be between the chair and the keyboard, but I have not found the problem.
Does anyone have an idea what could be causing non-DMA SPI access to fail after doing a GPDMA transfer with it? In the meantime I'll dive into the documentation and will update if I've found the culprit.
Also I need to check out this:
https://community.st.com/s/global-search/GPDMA
Yes.
The issue was with HAL drivers (stm32u5xx_hal_dac.c).
In the file stm32u5xx_hal_dac.c on line number 869 we have function HAL_delay(1);
We need excepting HAL_delay(1) from the code and callbacks start working and SysTick_Handler() isn't stuck.
I think it's a bug of the drivers and developers will fix it.
**********************************************************************
**********************************************************************
/* Process Unlocked */
__HAL_UNLOCK(hdac);
if (status == HAL_OK)
{
/* Enable the Peripheral */
__HAL_DAC_ENABLE(hdac, Channel);
/* Ensure minimum wait before using peripheral after enabling it */
HAL_Delay(1);
}
else
{
hdac->ErrorCode |= HAL_DAC_ERROR_DMA;
}
/* Return function status */
return status;
}
**************************************************************
**************************************************************
