• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 787 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320C6678: srio 4x setup fail

user4432861
Prodigy 40 points

Part Number: TMS320C6678

Hi, Experts:

we have boards based on C6678+Xilin kintex7, 6678 and K7 connected with SRIO. The program work fine for years, use SRIO port0 4x mode, and four lane setup ok.

Recently,  4x setup failed   when some code (SRIO-Configuration-independent) changed.

For example, 4x setup fail when the following code   in evm_init()  

         platform _write_configure(PLATFORM_WRITE_UART);

                  changed   to

         platform _write_configure(PLATFORM_WRITE_ALL);  or platform _write_configure(PLATFORM_WRITE_PRINTF);

Value of LANEn_STAT0  reg（addr 0x0290E010, 0E030,  0E050, 0E070）：

               when ok               when 4x fail(lane1 & lane 3 not sync）

LANE0, 0x00007008               

LANE1, 0x00107008        0x00104F08

LANE2, 0x00207008

LANE3, 0x00307008        0x00304F08

whenn 4x ok, lane0 and lane3 DspTx signal waveform ,  Sync & Skip(k28.5 k29.7) data pattern can be  found 


whenn 4x fail, lane3 and lane0 DspTx signal waveform  ,  lane3 has active signal  400ms , then no signal (here srio discover timer value 0xf),  (if srio discover timer value =0x2, signal presents for about 32ms ) 

when waveform of lane3 expanded,  k28.5 k29.7 data pattern can be  found , and the siganl qualitity looks fine

[development tools:  ccsv5.2(c6000_7.4.0 compiler), bios_6_33_06_50, mcsdk  , pdk_c6678_1_1_2_5,xdctools_3_23_4_60 ... ]

 My question:

The program was fine before, so the SRIO cfg is fine too,  Now the modification of code is nothiong to do with the SRIO cfg,  how this problem  generated?

Is the PHY layer statemachine halt ?  As the RapidIO Specification said, there should be some signal on the lane, IDLE sequence or Sync sequence

  • 0
    Prodigy 40 points

    The .map file has no changes before and after the modification of code.

    And the .out file almost the same , onley one byte modifed, which is the inParam for platform_write_configure.

  • 0 in reply to user4432861
    TI__Guru**** 161600 points

    Hi,

    Can you inspect the SRIO register values when ok and when fail? Is there any change in the reg values?

    I cannot say from first glance, but it seems there might be some race condition happening when using PLATFORM_WRITE_ALL, or there is a lack of bandwidth in some buffer, need to check further.

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 40 points

    Thank you very much for your reply. 

    The  'allRegSnapShot'  result exported by TCI6678_8_Srio_v0.13.gel,  there are only 2 diffirences

    1. LCSBA    

        when ok : GEL Output:  LCSBA[30:0] ---> 0x50600001

        when fail: GEL Output:  LCSBA[30:0] ---> 0x00000000

    2. LSUn_REG2.DSP_ADDRESS     ---> 0x80228670

        when ok : GEL Output:  LSUn_REG2.DSP_ADDRESS     ---> 0x80228670      

        when fail: GEL Output:  LSUn_REG2.DSP_ADDRESS     ---> 0x802286A0

    allRegSnapShotWhen4xOk.txt

    allRegSnapShotWhen4xOk.txt

    allRegSnapShotWhen4xFail.txt

    allRegSnapShotWhen4xFail.txt

  • 0 in reply to user4432861
    TI__Guru**** 161600 points

    Hi,

    Sorry for the delay, I am not able to find anything from the register values. It seems that when your transaction fails, you don't have any local configuration space address. However looking at the SRIO initialization sequence you should set this to 0x0 (section 2.3.15.3 Peripheral Initializations).

    I will keep looking into this. Again, sorry for the delay.

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    TI__Guru* 95265 points

    Hi,

    I looked at the platform_write_configure()=====>platform_write(), when you change this from UART to ALL or PRINTF, it also prints from the CCS console, this may call some functions in the rts6600_elf.lib. I don't see any relationship between printf() and SRIO failure.

    Something you can try: 

    1. do the SRIO init first, then do platform_write_configure(), will this change the behavior?

    2. totally remove  platform_write_configure(), will this change the behavior?

    3. Add some time delay between platform_write_configure() and SRIO init.

    4. try to increase the stack, heap size

    Regards, Eric 

  • 0 in reply to lding
    Prodigy 40 points

    Hi

    Thank you very much.

    Resolved.

    the root cause is the time delay

         1. totally remove  platform_write_configure() or platform_write(), work fine.

         2. then add delay at the same postion, The problem arises again.

    I thought FPGA would wait a long time for init,  but it looks like that there is  a shorter allowed time window, and DSP miss the window due to the time delay.

    Always lane1 and lane3 fail?

    RapidIO spec Part6, 1x/Nx_Initialization State Machine ,

    when in 4x mode, lane0 is the main lane, and lane2 is the redundant lane, they will start sync together  at 'SEEK' state, and in my project success(other lane is shut down), so lane0 and lane2 ok first

    then  lane1 and lane3 will start sync at 'DISCOVERY' state, and timeout occurs here because the time delay.  lane1 and lane3 fail. 

    So I gone the wrong way, the communication quality of the lanes themselves are ok.