How do I receive an arbitrary number of bytes over a slave SPI peripheral using DMA?

[Mike xx]

If I want to receive a known number of bytes I can use the library function:

HAL_SPI_Receive_DMA()

But I would prefer it if when nSS falls to check how many bytes have been transferred and interrogate the DMA buffer.

An alternative is to poll, using FreeRTOS, the DMA peripheral to see how many bytes have been received but would prefer an interrupt basis.

Are there any examples of this approach of receiving nominal SPI data as a slave?

[waclawek.jan]

> when nSS falls 

Isn't this the very definition of EXTI interrupt?

JW

[Mike xx]

Yes, but that wouldn't be ideal. The HAL libraries don't cater for this, by independently controlling enabling the SPI peripheral SxCR->EN.

The main issue is a framing error would never be detected. If a stream is corrupted that results in byte misalignment the MCU will never know. It will never find the end character or find start the start character.

If nSS is used by the peripheral hardware then errors can be detected.

[waclawek.jan]

> Yes, but that wouldn't be ideal. The HAL libraries don't cater for this,

Then you might want to accept the fact, that the HAL libraries for your application are not ideal.

> If nSS is used by the peripheral hardware then errors can be detected.

NSS is still be used by the peripheral hardware, of course.

JW

[Mike xx]

I accept the HAL libraries are for the more general cases. Prior to STM32Cube I was using earlier toolchains such a YAGARTO where you wrote your own peripheral drivers.

I have tried for the NSS to be used by the peripheral hardware, but it seems you can't use the NSS for both the peripheral hardware as well as an interrupt in it's own right.

[waclawek.jan]

> it seems you can't use the NSS for both the peripheral hardware as well as an interrupt in it's own right.

You can. What you see is a rather nonsensical restriction of "libraries" - Cube and its predecessor, SPL, do the same.

Did you see the link I posted above?

JW

[Mike xx]

Many thanks, I have now. I didn't immediately associate the blue letering with a hyperlink.

I wil report back.

[waclawek.jan]

> I didn't immediately associate the blue letering with a hyperlink.

Probably most users don't as salesforce (the crap used here instead of proper forum software) in their infinite wisdom chose to ignore usability in favour of modern look and feel (the unwritten but decades old convention is to underline the hyperlinks).

There's nothing more in that linked article than what I wrote above. There are incantations in Cube which set a pin as EXTI, if you call them after the autogenerated setup. I don't Cube. Try to search this forum, this is a recurrent theme.

JW

[Mike xx]

> Try to search this forum, this is a recurrent theme.

I felt your reply was terse and understood by the writer but not all those who read it. Your link gave a good description.

If it is a recurrent theme then the Cube libraries ought to ignore the GPIO->MODER register whilst setting up interrupts and allow dual use of pins.

The Cube is a learning curve in it's own right, albeit a fast one. There is very little info in these forms regarding using a slave SPI with DMA and using interrupts on the NSS pin. I accept there may be more generic solutions of using External Interrupts on AF pins.

Many thanks again for pointing me in the right direction. It's working brilliantly.

[Mike xx]

I cheated and use STMCubeMX to generate the code for the EXTI interrupts and made a copy.

I then reverted back to SPI hardware and implemented in user code the removed code.

Because the libraries reset the GPIOx->MODER register back to "00" the easiest solution was to ensure the MX_SPIx_Init() ran after setting up the interrupt. That way the GPIO registers would be overwritten with values suited to the SPI peripheral.

As far as I can tell I have best of both worlds.

Many thanks.