This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: Problems with FSI speed with fibre optic with TMS320F28388D

Part Number: TMS320F28388D

Good morning, colleagues,

I wanted to ask you about a problem I have been having when using the FSI of a TMS320F28388D microcontroller.

I am testing the following example "fsi_ex1_loopback_cpucontrol.c" and it is the usual code for an External Loopback.
I have done a test with two breadboard cables connecting between GPIO27 (TX CLK) and GPIO9(RX CLK) and between GPIO26(TX D0) or GPIO8(RX D0). Here is a picture of the setup.

With this configuration I have managed to get the code to work properly when debugging at 50Mhz, 25MHz, etc... The rxEventSts is 2112(data frame) and 2624 (ping frame) that indicates the RX is receiving well the frames. The txEventsSts is 1 that means it is transmitting well.

However, for the application I want to develop I need to communicate via optical fibre, so I have used R-1624Z and R-2624Z transmitters and receivers respectively. The assembly I have done is with the same GPIOs but taking the TXCLK, RXD0, RXCLK, RXD0 color-wire with a flat cable to a board with the 2 transmitters and the two fibre optic receivers. The assembly is as shown.


Once I have checked that the connection is correct and I do the debug, I have had the following problems. If I configure the CLK of the FSI at 10MHz it works fine (FSI_PRESCALE_10MHZ). 

However, when I increase the frequency to 25MHz I am confronted with the following:
- If I leave the code as it is by changing only the 25MHz prescaler I get RX INT2 jumped and the program stops. I see that the txEventSts is at 1 and therefore a send has been made but the rxEventSts is at 1, which means that the ping watchdog counter has been completed.

- If I comment out the lines "FSI_enableRxInterrupt(FSIRXA_BASE, FSI_INT2, FSI_RX_EVT_PING_WD_TIMEOUT);", "FSI_enableTxPingTimer(FSITXA_BASE, txPingTimeRefCntr, txPingFrameTag); "and "FSI_enableRxPingWatchdog(FSIRXA_BASE, rxWdTimeoutRefCntr);" so that it does not appear in the interrupt, now the error appears in the Main at the end of the while loop in ESTOP0 and txEventSts is 1 and rxEventSts is 0 so I don't know what could be happening when I do this. 

So the maximum speed I could reach with fiber was 10MHz, and because of these errors. I would be very pleased if you could help with this issue.

However, I did another test, this time I did not use the flat cable and directly connected the coloured wires from the GPIOs to my fibre optic card connectors as shown below.

However, I did another test, this time I did not use the flat cable and directly connected the coloured wires from the GPIOs to my fibre optic card connectors as shown below. This test shows interesting things but I don't know what I can take from this. The important news is that by making this connection (exactly the same as the previous one but without the flat grey cable) 25MHz COMMUNICATION worked! (FSI_PRESCALE_25MHZ).

Nevertheless, I want to work at 50MHz (FSI_PRESCALE_50MHZ) and this is still not possible.
- As the code is (with the 50Mhz prescaler) even if I comment the lines "FSI_enableRxInterrupt(FSIRXA_BASE, FSI_INT2, FSI_RX_EVT_PING_WD_TIMEOUT);", "FSI_enableTxPingTimer(FSITXA_BASE, txPingTimeRefCntr, txPingFrameTag); "and "FSI_enableRxPingWatchdog(FSIRXA_BASE, rxWdTimeoutRefCntr);" or if I write false in bool variable "isRxFrameWdEnable" I have the following errors:

(The pictures are the same as showed above but is the same issue)

Basically is the error I obtained in the case with the flat grey cable when I commented the INT2 lines. But here appears whenever I comment it or not. 

I would like to know if you could help me with this issue in order to obtain a speed of 50Mhz (these fibers can work with this speed until 120m) and what could be happening with this errors and if there is any parameter I could change in order to increase the time of the counters to avoid this errors of timing if are errors of timing (Im not sure if it's for this cause).

I will wait for your answer. Have a nice day.

BR,

Pedro

  • Hello,

    Due to US holiday, please expect a response by 20th February.

    Thanks & Regards,

    Sinchita

  • Hi Pedro,

    Please view the response to this thread asking about a similar setup. Can you scope the clock signal on the receive side and verify that it meets the timing requirements in section 7.13.2.2.1 FSIRX Electrical Data and Timing of the datasheet? If you scope the clock signal on both the FSI transmit side and the FSI receive side, do you see a consistent delay between the two? If so, you could potentially use the delay line feature of the FSI receiver to adjust for the skew. See the following application note.

    Best Regards,

    Delaney

  • Good morning Delaney,

    Here, I attach two photos showing both CLK and D0 transmission and CLK and D0 reception.

    The signals shown are:
    - Yellow: TX CLK
    - Green: TX D0
    - Red: RX CLK
    - Blue: RX D0

    The clock is 25MHz. As you can see, there is a little distortion in the signal but I am not too worried about it. What you can see in the D0 data signals is that when the value changes in TX until that change in RX arrives in D0 there is practically one clock cycle, about 38-39ns. The same happens with the clock as you can see in the first image. When a transmission starts the TXCLK is displayed before the RXCLK.
    I have tried using the FSI_configRxDelayLine() function but I don't see it doing anything although I am not sure if I have used it at the right point. I am with the project "fsi_ex1_loopback_cpucontrol".

  • Hi Pedro,

    If you take out the data frame transmission and keep just the automatic ping frames, are you seeing periodic ping frames when you scope RX D0 (at 25MHz)? When the ping watchdog error occurs, can you verify the RX_PING_WD_CNT value is equal to the RX_PING_WD_REF value in the Register View?

    Since the scope capture doesn't appear to have skew between the RX CLK and RX D0 lines, I don't believe a delay should be necessary.

    Best Regards,

    Delaney

  • Hi Delaney,

    Now I'am testing with the second configuration without the grey cable, directly with the colour wires that makes the 25MHz possible but not the 50MHz. What I see if I put the prescaler of 50MHz and I debug, I I see the PING CNT doesnt't reach PING REF watchdog as ypu can see in yellow:

    About the skew I don't see any delay between the RXCLK and RXD0 or TXCLK and TXD0, so yes, as you said, I think that it's not necessary to add a delay.

    Thank you for you time, I will wait for your answer. 

    Have a nice day,

    Pedro

  • Hi Pedro,

    Please view the response to this thread asking about a similar setup. Can you scope the clock signal on the receive side and verify that it meets the timing requirements in section 7.13.2.2.1 FSIRX Electrical Data and Timing of the datasheet? If you scope the clock signal on both the FSI transmit side and the FSI receive side, correctionFSI RX CLK line and FSI RX D0 line, do you see a consistent delay between the two? If so, you could potentially use the delay line feature of the FSI receiver to adjust for the skew. See the following application note.

    Best Regards,

    Delaney

  • Hi Pedro,

    The screenshot you show does not indicate a ping watchdog error which is expected since the RX_PING_WD_CNT hasn't reached RX_PING_WD_REF. That ESTOP instead means that either the TX or RX INT1 hasn't been called. If you check the rxTimeOutCntr and txTimeOutCntr, which one is 0? Based on the scope capture, I would assume the issue is the noise on the RX side. It could be counting a 1 as a 0 or a 0 as a 1 and never detecting the start of frame (1001), or getting an invalid value for the frame type etc. In section 7.6 Electrical Characteristics of the datasheet, it specifies that an incoming signal is counted as logical high when it reaches 2.0V (VIH) and a logical low when it is below 0.8V (VIL). If you wanted to verify that the incoming signals are being counted as high/low correctly, you could measure the voltage of the noise spikes and make sure they are within the threshold. 

    Best Regards,

    Delaney

  • Good morning Delaney,

    Thank you very much for your reponse. I have read again the datasheet of the transceiver of DC signal / optic fiber. If you read it, https://docs.broadcom.com/doc/AV02-4369EN , it says that can reach a maximum of 50Mbaud but here the TXD0 transmission at 50MHz is 100Mbps as it changes in both edges. So maybe it is the root of the problem. About the counter you said, I attach you a capture that shows that neither of the two counters has reached 0

    Thank you very much for your reponse. Have a nice week Slight smile

    BR,

    Pedro

  • Hi Pedro,

    You are correct, data is transmitted/received on every clock edge of the FSI clock so this could be the cause of your issue. Since this screenshot is hitting the ESTOP in the interrupt rather than in the main, it makes sense that the counter values aren't zero at this point. It is likely the same ping watchdog error you were seeing before.

    Best Regards,

    Delaney