SCI jitter

No one would have something to suggest?

Thank you in advance,

    Paolo

Hi,

I would like you to go through this doc:

http://www.ti.com/lit/an/slla173/slla173.pdf

Regards,

Gautam

Dear Gautan,

thank you for your answer: the application report you sent me is very interesting.

Anyway I'm quite sure that the problem is not the tranceiver but the SCI peripheral.

I hope you can see the following image:

In the left side you can see the master request and in the right side the slave answer. 

"Jitter A" is a software Jitter: it is when the software drive the tranceiver to tx data. This jitter is 88 nsec.

"Jitter B" is the SCI peripheral Jitter: 330 nsec.

The software code is:

GpioDataRegs.GPACLEAR.bit.GPIO13 = 1; //To drive the tranceiver for Tx data
asm(" nop");asm(" nop");                                 //Wait
ScibRegs.SCITXBUF = pt->txbuff[0];             //Start to tx Data

The software is running in RAM with interrupt disabled. The CPU clock is 144 MHz and the SCI baudrate is 3 MHz.

It's impossible that the software has this jitter (330 nsec !!)

In addition, "jitter B" is equal to the baudrate and I do not think this is a coincidence (1 / 3MHz == 333 nsec).

How can I eliminate this jitter?

I think I should work on the SCI peripheral: reset it, stop and restart his clock ... I don't know.

What do you think about?

Hi Paolo,

If I'm not wrong, you might've have tried millions of implementations already to solve this issue! But all in vain...

This is a very unusual jitter that you're experiencing and I agree with:

 In addition, "jitter B" is equal to the baudrate and I do not think this is a coincidence (1 / 3MHz == 333 nsec).

Also, can you brief me with what kind of issue you're facing due to this jitter?

Regards,

Gautam

Hi Gautam,

I need to answer from the DSP in less time. Now I'm able to answer in 700-800 nsec but I should in 400-500 nsec. With a jitter of 333 nsec answer in 400-500 nsec (respecting the timing of the tranceiver too) is almost impossible.

If answer from the DSP in 400-500 nsec is impossible we need to use an FPGA.

Regards,

   Paolo

Very True!

 How can I eliminate this jitter? Can I, for example, turn off and on the clock of the SCI?

The above solution is not an efficient way of handling SCI. Also, is the current baud rate at its maximum value? Please state the current baud rate in terms of bps.

Regards,

Gautam

Our legacy bus works only at 3 Mbit = 3 MHz = 3000000 bps.

To obtain this frequency I use:

SysCtrlRegs.PLLCR.bit.DIV = 6;

SysCtrlRegs.PLLSTS.bit.DIVSEL = 2;

SysCtrlRegs.HISPCP.all = 0;

SysCtrlRegs.LOSPCP.all = 1;

XintfRegs.XINTCNF2.bit.XTIMCLK = 1;

...

ScibRegs.SCIHBAUD = 0;

ScibRegs.SCILBAUD = 2;

I have an external oscillator at 48 MHz, then the baudrate is  

((48/2*6) / 2) / (8*(2+1)) = 3 MHz

Regards,

    Paolo

Hi Paolo,

I would also like you to go through this doc: http://www.ti.com/lit/an/slla272b/slla272b.pdf

Which takes care of physical aspects of RS485 based communication.

Jitter's introduced due to cable lengths and baud rates.

Do let me know whether this is helpful.

Regards,

Gautam 

Dear Gautam,

thank you very much for your documents: send me all you have on RS485 please.

Anyway the problem I have is different: I have problem with 10 cm of cable!

These days I made a lot of tests and now I'm sure that the jitter is on the SCI peripheral. Is there any way to "synchronize" the SCI in Tx? Is there some hidden registry where I can verify the "clock state" of the SCI in Tx?

I thought of a possible solution: to use SCIA to receive and SCIB for transmit but for me is very difficult to make a test. What do you think about this solution?

Regards,

  Paolo

Hi Paolo,

I thought of a possible solution: to use SCIA to receive and SCIB for transmit but for me is very difficult to make a test. What do you think about this solution? 

-> You can check with this configuration too, but I don't think you'll be able to observe much difference (Do check). 

Is there some hidden registry where I can verify the "clock state" of the SCI in Tx? 

-> You won't be able to monitor the clock state. You can monitor the baud rate though. 

One suggestion: Please go through SCI docs of the controller you're using thoroughly. Also, somehow I feel this jitter has nothing to do with SCI configuration.

Regards,

Gautam

Hi Gautam,

           You can monitor the baud rate though.

-> How can I monitor the baud rate?

          Please go through SCI docs of the controller you're using thoroughly.

          Also, somehow I feel this jitter has nothing to do with SCI configuration

-> I don't understand exactly what do you mean. Do you think the jitter is made by the SCI peripheral or not? If the Jitter has nothing to do with SCI configuration, why I need to go through SCI docs?

Regards,

    Paolo

Hi,

I asked you to go through the docs, as you felt sure that there's some issue with SCI peripheral. The later was my opinion, that you might be missing something else. I've worked on lot of SCI based projects and they were crystal clear with no jitters. Actually, I'm myself observing such kind of jitter for the first time. So, please try covering all the suggestions, as simultaneously you'll be eliminating all your doubts!

Regards,

Gautam

Hi Gautam,

at the end I reproduced something very similar to the problem using an eZdsp F28335.

In fact the jitter is more or less 1 bit:

I used the P8 connector. I made a short circuit between P8.9 (GPIO0) and P8.15 (SCIRXDB) to "emulate" an asyncronous start bit for the SCI peripheral.

In the previous figure, channel 1 is on P8.5 (SCITXDB), channel 2 is on P8.35 (GPIO26 for triggering) and channel 3 is on P8.9.

As you can see there is a jitter of 306 nsec.

I attach the source code (the project file is TestFPUStdRTS.pjt) 

Let me know if you are able to reproduce the situation and what is the problem in my source code.

1057.eZdsp.zip

Regards,

     Paolo

Hi,

Can you check this project for your eZdsp F28335? Let me know about jitter occurrence.

2318.scia_loopback_interrupts.zip

Regards,

Gautam

Hi Gautam,

I tested your project but it is very difficult to verify the jitter. In fact, the application is "bombarding" on the SCIB and it is impossible to understand if the bit is true or is jitter by using the oscilloscope.

Have you tried my application? Please note that if you  just add a "nop" in the right place in the code, the jitter changes or desappears always in the same way: with the same nop the behavior of the jitter is always the same.

My "fpga" colleague call it "alea" or "randomness". I call it "bug". But maybe I can do something in the source code to avoid the jitter (but I don't want to add "random nop"). 

Obviously I'm joking: it would be the first time since 2001 that I find a problem on a C2000's peripheral. Anyway, in this case I have some doubt about the device.

Let me know what you think and in how  we can move forward.

In the meantime I will try to do some other test with your project

Regards, 

    Paolo

Hi Paolo,

As you've mentioned yes, SCI is in burst transmission mode. Also there exist no jitters, I've checked it myself.

That's exactly why I gave it to you to check. Do try editing the code; modify it to single byte mode from burst. 

Let me know; jitter reduces or not.

Regards,

Gautam

Hi Gautam,

ok, I will try your project.

In the meantime you could check out the software that I have provided you where the problem is reproduced easily.

Why not?

We already have a test case with which you can easily reproduce the problem!

I don't know the implementation of the SCI, but my belief is that the state machine that manages the serial reception were done by 8 states (see paragraph 1.2.7 of sprufz5a).

This state machine is probably "active" while transmitting, synchronizing somehow the byte transmitted to the start bit received. 

In fact, in my project, until I provided a start bit in rx to the SCIB using an asynchronous GPIO, the jitter has not been reproduced.

If this is true, I guess I'll have to change a lot your project (where the transmit and receive synchronous because they are actually made ​​from the same device).

Regards, 

    Paolo

Actually there's some other work going on, on  my 28335 control card. Once free, will try your project out and inform you asap.

Regards,

Gautam

Hi Gautam,

I think I've reproduced the problem with more or less your project.

I changed

1) To obtain 3.125 Mbit:

SysCtrlRegs.HISPCP.all = 0x0000;
SysCtrlRegs.LOSPCP.all = 0x0001;

#define LSPCLK_FREQ CPU_FREQ/2
#define SCI_FREQ 3.125E6

2) To simplify, I disabled SCIA

3) Added a GPIO26 to trigger with the oscilloscope

EALLOW;
GpioDataRegs.GPADAT.bit.GPIO26 = 1;
GpioCtrlRegs.GPAMUX2.bit.GPIO26 = 0;
GpioCtrlRegs.GPADIR.bit.GPIO26 = 1; //output a 1 //P8.35
EDIS;

4) the Tx interrupt routine scibTxFifoIsr now is

Uint16 i;

for (i=0;i<paolo;i++)
;
paolo++;
if (paolo>10)
paolo=0;

GpioDataRegs.GPASET.bit.GPIO26 = 1;
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0x1; // Send data
ScibRegs.SCITXBUF=0xff; // Send data

GpioDataRegs.GPACLEAR.bit.GPIO26 = 1;

ScibRegs.SCIFFTX.bit.TXFFINTCLR=1; // Clear Interrupt flag
PieCtrlRegs.PIEACK.all|=0x100; // Issue PIE ACK

I introduced a variable delay BEFORE the GpioDataRegs.GPASET.bit.GPIO26 =1; using a for cycle.

But I see on the oscilloscope a variable jitter between GpioDataRegs.GPASET.bit.GPIO26 = 1; and the start bit of the first byte txed by ScibRegs.SCITXBUF=0x1; 

In the attached figure you will find on channel1 SCITXDB and on channel 2 the triggering signal of GPIO26

If I comment out the for cycle the figure becames

The source code is

3817.Irq.zip

Let me know if you have news for me or if you want some other test.

Regards,

    Paolo

Its very strange; I've never experience such jitters ever. Anyways, I'll inform a TI employee about your issue. 

Regards,

Gautam

Hi Gautam,

Thank you very much.

Regards,

    Paolo

Hi Gautam,

have you some news for me?

Regards,

   Paolo

Sorry mate, no news. By the way why don't you check with your local FAE? He might help you solve this issue (if its solvable).

Regards,

Gautam

Hi Gautam,

I already checked with the local FAE before writing here: if you do not knok the answer imagine the FAE ;-)

Anyway, In the meantime I think I found a work around but I'd like to be sure that there are no problems in my work around.

First of all, I'm pretty sure that the SCI transmits the start bit with "quantized" time depending on the baud rate. For example, if the baud rate is 3 Mbit (1 bit every 333 nanosec), the start bit comes out the time t0 = 0 nanosec, or t1 = 333 nanosec or t2 = 666 nanosec and so on.
At this point I used the SCIA to receive and the SCIB to transmit. So, I reset the serial port using SCICTL1.bit.SWRESET before I begin transmitting. In this way  I have no jitter on the output of the start bit transmission.
That there could be problems with this solution?

Regards,

    Paolo

Hi Paolo,

 I already checked with the local FAE before writing here: if you do not knok the answer imagine the FAE ;-)

 So, I reset the serial port using SCICTL1.bit.SWRESET before I begin transmitting. In this way  I have no jitter on the output of the start bit transmission.

Nice approach, this should not affect your communication. Anyways, just check the Reset config:

Regards,

Gautam