AVR32 Synchronous Serial Controller (SSC) 's Problems

AVR32: Synchronous Serial Controller (SSC)'s Strange Behavior

UltimaSerial

Frame-Sync synchronous serial communication is the perfect protocol for transmitting data of multiple channels.

Here is how a typical TDM (time-division multiplexed) Frame-Sync synchronous serial data communication should work:

Frame-Sync is always in-sync with the data from the first channel
There should be no Frame-sync before and after the data transfer
No matter when you inspect the data stream you know exactly how to align the data from different channels

With these features, this protocol will never result in channel rotation even when there are glitches on the lines

Here, we will use Atmel UC3A (we use UC3A0512 in our test, but the following applies to both UC3A and UC3B families) 's Synchronous Serial Controller (SSC) and DMA controller to

receive data from a serial device
process the data and output to a downstream TDM receiver, possible another UC3A

both using frame-sync serial interface

Spec of the frame-sync serial device (input)

Each frame contains 8 channels of data, each data is 24 bit
It generates Frame-sync (FSync), SerialData (sData) and SerialClock (sClk)
FrameSync is a positive pulse, lasting two sClk cycles.
The sData comes in MSB first
The sData should be latched on the rising edge of sClk
The first bit of sData starts at the first rising edge of sClk after the rising of FSync
This is a passive device, with no register

Input Settings

Since sClk is provided by peripheral, the maximum clock speed of sClk is Master clock to AVR divided by 2
Set ssc->rcmr.START = 5 to detect the rising edge of FSync, spec.6
Set ssc->rcmr.CKI= 1 to latch the data on the rising edge of sClk, spec.6
Set ssc->rcmr.CKS= 2 to receive RX_CLOCK provided by the peripheral, spec.2
Set ssc->rfmr.DATNB= 7 for spec.1. If only the first n channels are needed, set it to n-1
Set ssc->rfmr.DATLEN= 23 for the 24 bits in the data, spec.1
Set ssc->rfmr.MSBF= 1 for MSB first, spec.5
Set ssc->rfmr.FSOS= 0 since Frame Sync is proviced by peripheral, spec.2
SSC uses a PDCA channel to send data to memory,
- If byte size if selected, only the lowest 8 bits are sent over
- If 16-bit (half word) size is selected, only the lowest 16 bits are sent over
- If 32-bit (word) size is selected, all 24 bits are sent over, with 8 stuffed bits in the MSB
The SSC signals are
- PA17 : SSC-RX_Data
- PA18 : SSC-RX_CLOCK
- PA19 : SSC-RX_FRAME_SYNC

Protocol of intended UC3A SSC serial output

Each frame contains 4 channels of data, each data is 16 bit
UC3A generates Frame-sync (FSync), SerialData (sData) and SerialClock (sClk) @ MasterClock/2, where sClk is transmitted only during data transfer
FrameSync is a negative pulse, lasting two sClk cycles.
The sData comes in MSB first
The sData should be shifted out on the rising edge of sClk
The first bit of sData starts at the first rising edge of sClk after the rising of FSync

Output Settings

Since sClk is provided by UC3A, ssc->cmr = 1, spec.2 ;
Set ssc->tcmr.START = 5 to detect the rising edge of FSync, spec.3
Set ssc->tcmr.CKI= 1 to shift out the data on the rising edge of sClk, spec.5
Set ssc->tcmr.CKS= 2 to generate TX_CLOCK, spec.2< /font>
Set ssc->tcmr.CKO= 0 to generate TX_CLOCK, spec.2< /font>
Set ssc->tcmr.STTDLY= 1, transmit start delay < /font>
Set ssc->tcmr.PERIOD= 100, clock rate
Set ssc->tfmr.DATNB= 3 for spec.1. If only the first n channels are needed, set it to n-1
Set ssc->tfmr.DATLEN= 15 for the 16 bits in the data, spec.1
Set ssc->tfmr.MSBF= 1 for MSB first, spec.4
Set ssc->tfmr.FSOS= 1 since Frame Sync is a negative pulse, spec.3
Set ssc->tfmr.FSLEN= 1, spec.3< /font>
Set ssc->tfmr.FSDEN= 1, spec.3
SSC uses a PDCA channel to retrieve data from memory
The SSC signals are
- PA16 : SSC-T_Data
- PA15: SSC-TXCLOCK
- PA14 : SSC-TX_FRAME_SYNC

Not-so-good result:

SSC has problems in output

To demonstrate the problem in SSC output problems, the following output pattern is used so that it can be easily identified on a logic analyzer:

buffer_out[0]=0xFFFF;
buffer_out[1]=0;
buffer_out[2]=0xAAAA;
buffer_out[3]=0x0505;

buffer_out[i]=0xFFFF; where i>3

Make sure buffer_out is multiple of channel count for alignment

Here is what we observed:

The Frame Sync exists even when there is NO data to transfer, refer to the capture before the cursor. As the result, the downstream TDM receiver will clock in a lot of useless data

When resuming from a pause, the Frame Sync are only in sync with the first data when DATNB<=1. Please note the first data of 0xFFFF is in sync with the FrameSync signal at the cursor.

The Frame Sync is NOT in sync with the first data when DATNB>1. In the following test, DATNB= 3 is used. Please note the data from the first channel (0xFFFF), which is immediately after the cursor, is now occupies the position reserved for the third channel. As the result, the downstream TMD/SSC receiver will run into channel rotation immediately

According to Atmel FAE, this is how their version of SSC supposed to work: the PDCA is independent of SSC so there is no real synchronization between them, and it exists in all AVR32 families. If a workaround is confirmed, I will post it here

Last update: 11/12/09

When resuming from a pause, the Frame Sync are only in sync with the first data when DATNB<=1. Please note the first data of 0xFFFF is in sync with the FrameSync signal at the cursor.