Hi All

Has anyone else had such a problem?

1) I use the SSC for transmission (16 x 16 bit words are transmitted by DMA or interrupt in a single frame).
2) The TF output is programmed to generate a pulse at the start of the frame.
3) The PERIOD is set to the same length as the frame so that the frame pulse is generated continuously.
4) The TK is generated only when there is a transmission.
5) Since frames are sent only randomly (not streaming) the tx is enabled only when there is data to be sent (otherwise the data is not necessarily synchronous to the frame) and the tx is disable once the frame has bee sent.
6) The problem is that the first bit sent is always '1' (eg. when all tx words are 0x0000) and the last bit doesn't have a clock associated with it. The last bit is visible and has the expected value but its TX clock is missing. Effectively the clock and data outputs are working correctly (correct number of clocks and correct data) but the clock is one period too soon [clocks out always a leading '1' and is missing for last data bit].
7) If the TK is operated in continuous mode this is not necessarily noticed since the synch is one clock before the first data bit and the last clock (and subsequent) are always available.

Any ideas??

Regards

Mark

Hi All

As a follow up I noticed the following slight strange behavior:
1) If I generate the clock continuously and adjust the receiver to synchronize on the TF->RF sync and start on the correct clock I can receive all data correctly, but there is always a final frame trigger and subsequent frame contents of 0xffff, 0xffff etc, even though the TF was stopped. This is using the LOOP mode where TK, TF and TD are internally connected to RK, RF and RD.
2) If I repeat the same test but not in loop mode, connecting the wires externally, all data is received correctly but the final empty frame is never seen. This suggests that the internal loop back 'sees' an additional trigger event, which is not visible on the real TF pin (?)

Regards

Mark

Hi Mark,

I know it is a bit late, but I can confirm the bug you reported. As a solution, I am:

1. Using the continuous clock,
2. Adding a new empty byte to the beginning of the data to be sent,
3. Shifting every data byte by one bit, in order to correct this clock deviation

There is a lot of overhead associated, and for my application I need to allocate a buffer only for this operation, in order not to mess with the user data buffer. If you found another solution, please let me know.

Regards
Luiz Fernando