• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 739 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.

C6657 IBL TFTP boot problem

Adam Koltys
Intellectual 560 points
Other Parts Discussed in Thread: CDCE62005

Hi,

I was having problems with tftp boot on EVM C6657.

First I upgraded fpga, but i didn't solve the problem.

After looking into source code of bootloader, I realized that there is a bug in ethboot.c file.

In source code there is delay after doing mdio configuration, for-loop is used, but the variables used in that loopare not volatile, so there is no delay.

After changing variables to volatile everything works better (i changed loop to do 2 times less cycles).

Actually its not a problem, its the way how to solve it if someone ever had such problem.

  • 0
    TI__Guru** 116170 points

    Hi Adam,

    Is your issue resolved by inserting the delay or are you still having issues booting over tftp.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 560 points

    Rahul Prabhu said:

    Hi Adam,

    Is your issue resolved by inserting the delay or are you still having issues booting over tftp.

    Regards,

    Rahul

    Hi Rahul,

    Yes, delay resolved the problem.

    Today i will test it on ~10 other devices. If there are any problems, I will write about them here.

  • 0 in reply to Adam Koltys
    Intellectual 560 points

    In one of the devices phy the issue sill occurs, but not always.

    It turned out that phy is being reseted by fpga, so I checked fpga source code and found out that reason for this can be wrong "clock2_pll_lock" state.

    I checked it on osciloscope and this signal state was wrong (but not always), and fpga was reseting phy with ~900kHz frequency. When heat sink is put on CDCE62005, problem occurs more often.

  • 0 in reply to Adam Koltys
    Intellectual 560 points

    Hi,

    The issue was finally resolved. Problem was caused by CDCE62005, pll sometimes didn't lock . Settings that were loaded to register 7 by fpga were incorrect, correct value is: 0xBD813B47.

    In files clock_spi2x.v and clock_spi3x.v in line 331:

    always@(*)
      case (ini_cnt)
        4'd8:    blk_mem_Write_data_buff = {1'b1, blk_mem_Write_data_buff_temp[30:27], 1'b0, blk_mem_Write_data_buff_temp[25:0]};
        4'd9:    blk_mem_Write_data_buff = {1'b1, blk_mem_Write_data_buff_temp[30:27], 1'b1, blk_mem_Write_data_buff_temp[25:0]};
        4'd10:   blk_mem_Write_data_buff = {32'h8000_8cd8};
        4'd11:   blk_mem_Write_data_buff = {32'h8000_9cd8};     
        default: blk_mem_Write_data_buff = blk_mem_Write_data_buff_temp;
      endcase   

    I chnged to:

    always@(*)
      case (ini_cnt)
        4'd7:   blk_mem_Write_data_buff = {32'hbd81_3B47};
        4'd8:    blk_mem_Write_data_buff = {1'b1, blk_mem_Write_data_buff_temp[30:27], 1'b0, blk_mem_Write_data_buff_temp[25:0]};
        4'd9:    blk_mem_Write_data_buff = {1'b1, blk_mem_Write_data_buff_temp[30:27], 1'b1, blk_mem_Write_data_buff_temp[25:0]};
        4'd10:   blk_mem_Write_data_buff = {32'h8000_8cd8};
        4'd11:   blk_mem_Write_data_buff = {32'h8000_9cd8};     
        default: blk_mem_Write_data_buff = blk_mem_Write_data_buff_temp;
      endcase 

    After I changed this in fpga program, I haven't had any issues.