Arduino for STM32

fpiSTM wrote: Thu Feb 06, 2025 2:30 pm Hard to answer without the full code.

As the SPI DMA is not (yet) supported by the core it probably comes from your code.

//STM32H750XBH6
#define USE_ARDUINO
#include "hal_conf_custom.h"
#include "STM32H750XBH6/Core/Src/main.c"
#include "STM32H750XBH6/Core/Src/stm32h7xx_hal_msp.c"
#include "STM32H750XBH6/Core/Src/stm32h7xx_it.c"

uint8_t pTX[8];
uint8_t pRX[8];

void setup(){
  HAL_MAIN();
  HAL_SPI_TransmitReceive_DMA(&hspi2, (uint8_t *)pTX, (uint8_t *)pRX, 8);
}

void loop(){}

#ifdef USE_ARDUINO
void HAL_MAIN(void){
#else
int main(void)
{
#endif

fpiSTM wrote: Fri Feb 07, 2025 9:45 am I don't think that simply adding the cube file is a good idea because some stuff are duplicated like weak function already overridden and don't which one the linker use.
You can see this topics on how to convert a Cube example in Arduino.
viewtopic.php?t=110

thisdp wrote: Fri Feb 07, 2025 12:40 pm DMA IRQs are disabled.

ag123 wrote: Fri Feb 07, 2025 2:29 pm

thisdp wrote: Fri Feb 07, 2025 12:40 pm DMA IRQs are disabled.

I think DMA IRQs are actually needed, some samples from HAL codes, this is for F4
https://github.com/stm32duino/Arduino_C ... pi.c#L1926

well I'm not sure, but in some of my codes, I've enabled them.
https://github.com/ag88/stm32duino_spi_ ... X.cpp#L148
either way do note that I've not tested my codes yet
viewtopic.php?p=15283#p15283

I think HAL uses them to update some status variables and closing ops such as to clear overflows, read / flush buffers etc.
https://github.com/stm32duino/Arduino_C ... pi.c#L2825

ag123 wrote: Sat Feb 08, 2025 3:52 am well, I'm yet to test my DMA codes
viewtopic.php?p=15283#p15283

so I do not really know if it works.
But that while I worked the codes, I noted that there can be conditions of overrun if data not read etc. e.g. that RXNE (receive buffer not empty) is set.
If those flags are not cleared and the next attempt / transaction to do SPI transfers starts, the next transfer may instead be reading data from the *last* transfer.

DMA uses the flags complete and half complete to indicate completion of transfers, if you do not use interrupts, you would need to check the flags (manually) in codes and respond when they are set. A trouble is, this would normally be ok, but you may not be able to use HAL_SPI_TransmitReceive_DMA if that use the interrupts. e.g. you may to write your own version of HAL_SPI_TransmitReceive_DMA to handle the half complete and complete events.

There are also some things that I'm not sure about such as HAL_SPI_TransmitReceive_DMA is likely async, i.e. it returns immediately instead of waiting for the transfer to complete. transfer is done completely independently off program codes and there is no interaction with your program codes.
If that being the case, when you read the receive buffer, e.g. after you called HAL_SPI_TransmitReceive_DMA, the transfer may actually not be complete. e.g. You would need to do additional checks e.g. to check the transfer counts etc.

stm32H7 has a complex / elaborate SPI peripheral with FIFO etc, along with a pretty complex DMA peripheral, you would need to review all that codes to see if you are missing anything handling SPI, the FIFO, and DMA etc. FIFO makes the prospects of checking those events SPI receive, DMA complete, half complete etc significantly more complicated. Normally, with DMA, you need to fill the buffer / count completely before the complete event is flagged.
And FIFO adds to the complexity as that also have some requirements e.g. in that if the FIFO is half filled, some data may remain in the FIFO.
For master, as you determine the clocks it is easier, but for slaves, the clock is determined by the master, and you are dealing with those added complexity.