How to make USART0 drive the SCK0 clock pin in master SPI mode?

I am trying to use USART0 in Master SPI Mode. Just as a test, I first set pin 70 (SCK0) to output, using "pinMode(70, OUTPUT)". Then (i know, that's not a clean way, but it's a test) i altered the "USARTClass::begin(...)" method in USARTClass.cpp, to directly set USART0 to MSPIM, by replacing

...

_pUsart->US_MR = config;
...

with

...
_pUsart->US_MR = US_MR_USART_MODE_SPI_MASTER | US_MR_CLKO | US_MR_CPHA | 0xC0;
...

I leave anything else unchanged in that routine.
Calling the (altered) routine with Serial1.begin(9600), and writing data to it with Serial1.write(data) does show the correct SPI data-bit-patterns at the TX1 pin, checked by oscilloscope.
However, SCK0 (located at the pin labeled SDA1 on the due board) stays on low (also checked by oscilloscope), no clock signal is submitted.

Obviously, MSPI-mode is switched on (the data-bit-pattern is SPI), i also set US_MR_CLKO, which should make the USART drive the SCK pin, and the assigned pin (A.17 or pin 70) is set to output.

What am i missing?

USART0 is connected to the ATmega16U2, used for USB programming and communication with the PC.
Also note that SCK0 is on peripheral B.

Serial1.begin(9600) is for USART1.

Hello dllloyd, thanks for your fast response!

I do think though, that Serial1 connects to UART0. At least, as you see in your diagram, UART0 is connected to DUE's pins RX1, TX1, and, in SPI mode, D70 (SCK0). There is a confusing index shift between the DUE and SAM notation, but, just to be sure, I tested the DUE TX1 pin with an oscilloscope, using Serial1, and got the expected SPI bit pattern. So, I'm sure that Serial1 is actually driven by USART0. I also tried Serial2 (with TX2, and SCK1) and had the same effect: the data pattern was there, no clock signal anywhere (i tested all pins).

A (trusted by me) pin out diagram tells about SCK0:
"SCK0 [Due Pin D70, labeled SDA1] allows Serial1 to be used for SPI", which also confirms my assumption.
and:
"SCK1 [Due Pin D54, labeled A0] allows Serial2 to be used for SPI"
The diagram is here: http://www.robgray.com/temp/Due-pinout-A4.png

In short, I'm still confused...
Would you have any other ideas?
Thanks again!

Yes, you're right about the serial connections. I've also tried using SPI mode of the USART without success.

EDIT:

I think the best approach would be to follow a similar method as the link below, but written to work with the SAM3X USART registers.

Scroll down to "SPI from the USART ... an alternative"

There really isn't much information out there on what it takes to get the Due's USART operational in SPI Mode (other than the datasheet). So I've decided to see what's possible.

The following code sends out a continuous byte stream on USART0 or USART1 set up as an SPI Master.
Tested SCK at 1, 2, 4, 7, 12, 14 MHz with divisors of 84, 42, 21, 12, 7, 6 respectively.

Interesting that the signals seemed OK at 21 and 28 MHz (using divisors of 4 and 3), but the data sheet says a divisor of 6 is the lowest you should go. The print monitor will display the status of various USART registers.

Due_USART0_SPI_Master.ino (4.97 KB)

Due_USART1_SPI_Master.ino (4.97 KB)

Hello dlloyd,
Thanks for the code! I'll try it over the next days.

cheers,
rlak

Hello dlloyd,

your code works great, I only needed to change the US_MR mode to 0x0401CE (important is the "1" in there) in order to get a phase shift between data and clock, which is required by the LED hardware.

The next step for me would be to have this running with DMA...

Thanks again!
rlak

Could you post an oscilloscope traces of the USART0 operating in SPI master mode? I'm trying to get it working ( transmitter only ) to write data to a series of 4 shift registers chained together.

They work just fine in SPI Bus mode 0 using the hardware SPI but I cannot get more than 1 to work correctly in USART0 SPI master mode. Can you confirm that only 8 bits / clock cycles are transmitted during each operation ( writing 8 bits to US_THR ). It seems the act of trying to shift data through the first register into the second isn't working correctly which is why I'm curious if there is other bus ( clk or data ) activity between transfers.