ATSAME5x SPI - Hardware controlled SS

[ubbut]

Hi,

I am trying to use the SPI "hardware controlled SS" functionality with a frame size of 16 bit.


I am using the sercom in SPI master mode.
I would like to set SS to low, send 16 bits and set SS to high. Then repeat this multiple times.
I am using the SPI with the 32bit extension and a LENGTH.LEN of 2. This way I can write 16 bits at once.

This works.


Since there is a lot of overhead switching the SS signal manually, I would like to use the Hardware controlled SS feature. However, it toggles the SS line after each BYTE, not after each 16 bit frame !

Is there a setting I am missing? Or is this a hardware limitation?


For the SS control I have tried an interrupt driven approach as well, but there is a lot of overhead - calling the interrupt function, performing task switching, and setting the SS signal takes about 700ns @ 120MHz


thank you

[WatchfulEye]

This is a hardware limitation. You must use software SS control to achieve your requirement.

[ataradov]

It is not really a limitation, the shift register is 8/9-bit. The 32-bit mode is there to reduce internal bus load for large transfers.

But I don't understand the scenario. Presumably you want to know when the transfer is done anyway, so you would incur that interrupt overhead no matter what.

[ubbut]

But I don't understand the scenario. Presumably you want to know when the transfer is done anyway, so you would incur that interrupt overhead no matter what.

No, in an optimal case I would use DMA to transfer multiple 16 bit frames with automatically controlled SS.

[ataradov]

I see. The only thing that comes to mind is DMA with linked descriptors and interleaved writes into PORT registers for SS control and the SPI registers for data. This is pretty annoying to setup and maintain desired SS timings, but might work.

And another thing to think about here is that TX DMA would be done as soon as the byte is sent into the shift register, which makes timings even more annoying.

[WatchfulEye]

It is challenging to do what you want as a background DMA task with the SPI peripheral. I did try to do something similar and struggled with the timings, the complex setup and a nasty erratum with linked DMA descriptors (which led to occasional transfer errors - roughly 1 in 10^5 transfers would experience an erroneous failure).

I ended up using DMA to bit-bang the SPI protocol via writes/reads to PORT. In my case, most of the data transmitted was static, and only specific fields needed to be updated. The price for the data transfer running autonomously via DMA was reformatting the data, and the inflation of the data buffers needed, as well as 3 DMA channels.

A subsequent revision of the software got rid of all that, and just used interrupts and a spin-wait between data frames.

[ubbut]

thank you all.

For another project I have used DMA with PORT successfully, but it was very annoying (this was on a SAMC, but I think it is similar on the E5x). You need 2 channels, one for setting bits and one for clearing bits* Furthermore, fetching the DMA descriptors takes quite long, this results in a delay between bit set and bit clear, this jitter can cause issues as well.

I have a new idea:

setting up a timer with PWM that outputs the SS signal continuously. This timer then triggers one 16 bit SPI transfer on each overflow. Have to work this out, but I think it might work.


* This is handled much more elegantly in STM devices. A single 32bit register is used to both set and clear port pins (The upper 16 bit set, and the lowe 16 bit clear, maybe it was the other way around). This way only one DMA channel is needed and there are no timing differences.

[honestgold]

does ATSAMA5DX have limitation on the SPI/DMA where you can only transfer max of 4095 words like the SAM uC?

[ataradov]

ATSAMA5 has full scatter-gather DMA, it can transfer any size.

What specific uC you are talking about? I don't really remember any with this limitation.

[honestgold]

We encountered the issue with ATSAM3X series uCs. You can chain multiple transfer together, but there is a transition time gap and the gap became an issue.

[honestgold]

Alex, I also want to ask if you have SAMA7 out yet with SOM? I am looking for crossover uCs with gigabit ethernet and several giga of RAM. We are very familiar with the ATMEL peripherals, but your product line is behind or less on features than others on those cross-overs. Or maybe SAMA7 is not mature yet with long list of errata?

What is Microchip's direction? Do they have plan to release something like NXP IMX8?
 

[ataradov]

SAM3X has DMAC and PDC, both support up to 65K transfers per transaction. The counters are 16-bits in size and I don't remember of any limitations on the supported values.

SAMA5 XDMAC controller is similar in style to DMAC, but it is way more advanced. The microblock level lets you specify 24-bit count (16 mil transfers).

[ataradov]

Alex, I also want to ask if you have SAMA7 out yet with SOM?...What is Microchip's direction? Do they have plan to release something like NXP IMX8?

  No idea, I don't work with MPUs and don't keep up with their releases.

[honestgold]

Sorry, the 4K limit was in SAM3U4C or SAM3A4C. Not sure if they fixed the bug in the newer chip releases. It was few years ago.
We had a project where we had to read 6K+ counts of SPI+PDC and encountered the issue. We ended up using the chain PDC and add a delay during transition. 

[ataradov]

Sorry, the 4K limit was in SAM3U4C or SAM3A4C.

All those devices use the same peripheral set. I still don't see where this limit would come from.

[SiliconWizard]

Since the initial point of the OP was "Hardware controlled SS", possibly the limitations they are talking about pertains to how long a SPI frame can be on a given MCU, regardless of DMA.

On some MCUs, it's not even possible to freely define the length of the SPI frame (in the sense of the MCU automatically handling the /SS signal over the whole frame rather than toggling it every word, or every n-word with n something fixed or with a limited max value.)

Never worked with this ATSAM series, but certainly on a number of MCUs, that specific point is a PITA and you (often) have to handle /SS "manually".

[ataradov]

All the MCUs mention here have hardware SS control, even hardware generation of timings before the first byte and between CS assertions. But there is no fixed frame length. CS is asserted automatically if the last transfer bit is set (can be done via DMA, but you would need to spread all your bytes into 32-bit words) or if another CS is requested.

I have never seen a hardware CS control that was universal. There is always some use case where it would not work.

The only limit like that that comes to mind is that in SAM G55 I2C controller supports automatic write+read (to set an address for EEPROM-like devices, for example). And if that mode is used, you can't have more than 255 bytes in the payload.