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

void _HwPktPoll( PDINFO *pi, uint fTimerTick ) never called or ("NO_PHY_CONNECTED") - C6455

Arnaud Maye
Intellectual 400 points

Other Parts Discussed in Thread: SYSBIOS

Hello Gents,

We are trying to bring EMAC interface UP and RUNNING on our own hardware. We have a code compiling and running well on the DSK6455. We are trying to troubleshoot what appears to be a MDIO issue. The EMAC/MDIO connections are routed through an FPGA and we are trying to verify the MDIO protocol itself.

We have two different issues, the first one being "NO_PHY_DETECTED" and I can fairly understand why and so on. The second one a bit more difficult is NDK not calling HwPktPoll() at all. I was hoping to read from experienced engineers what could actually make NDK not to POLL anymore, is there anything obvious I could check? I am surprised we are getting either NO_PHY_CONNECTED or no poll at all. The NO_PHY_CONNECTED error is thrown by _HwPktPoll() which indicates in these circumstance the function is called by NDK.

Best Regards,

Arnaud

  • 0
    TI__Guru* 96960 points

    Hi Arnaud

    Could you verify the BIOS clock is working? This can be done by looking at ROV or by adding a TSK_sleep (or Task_sleep if you are using SYS/BIOS) with some value (e.g. 1000) and confirm that the function is called and returns after the specified time. You can look at registers TSCL/TSCH before and after the TSK_sleep call. These registers contain a 1-1 count of the CPU speed. So an sleep of 1000 ms on a 700MHz CPU should a TSCL/TSCH delta of 700,000,000. 

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 400 points

    Hello Again Todd!

     

    Thanks for your almost immediate answer! I have checked ROV and I am not sure what I am looking at sorry for that. In "KNL" I can see the system tick increasing making me believe the kernel is not blocked and that clock is correct. In "TSK" I can see tsk_idle running but the Ndkstacktest task is blocked ( maybe because to use ROV I have to pause in CCS debug ).

    I have not went to the tsk_sleep scheme yet, can you let me know if on the ROV side things look fine?

    Thanks!

    Arnaud

     

  • 0 in reply to Arnaud Maye
    TI__Guru* 96960 points

    Arnaud,

    It looks like the System Clock tick is working. I have a couple generic questions:

    Which version of the NDK are you using?

    Which driver are you using?

    When you say HwPktPoll(), you are talking about the poll() function in the driver that is part of the nimuif.h NETIF_DEVICE structure...correct?

    The Ndkstacktest is probably blocked on a semaphore. (fyi, halting the processor to look at ROV does not impact the state of the target). I wanted to confirm the clock was working because the NDK TSK is driven by incoming data, outgoing data and by the BIOS System Clock. The poll function is driven by the clock to do async type things like protocol timeout handling, etc.

    Can you look the SEM section in ROV? Do you see the network task pending a semaphore. In the TSK view, you should see the network stack pending on that semaphore also. What is the time remaining in the TSK view?

    For example, I made a simple example that has two tasks pending on a semaphore with a timeout of 4 clock ticks (and 4 ticks are still remaining of the pend).

    Todd

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 400 points

    Hello Todd,

    Thank you very much about that. Because of your help I have learnt a lot of thing about NDK, SYSBIOS and ROV much appreciated.

    We have actually got more fluent around the implementation and been able to point finger on our FPGA firmware being between the PHY and the DSP, maybe you are curious so here was the list of problems:

    - Initially we have buffered MDIO clock in the FPGA and we are now directly passing thru.

    - There was a mistake in the firmare design where the designer thought MTCLK should be driven from DSP to PHY where it is the reverse way around.

    - On the MII side, there data was sampled on the wrong clock edge.

    - Some FPGA signal constraints were not implemented in the design.

    The most obvious been reading from PHY known value (0x141) on one register and seeing the DSP receiving 0x282 or 0x283, so obviously the bit polling could not go very well. Actually the link was up already but the NDK system would not figure it out.

    Once again thank you for your help and pointer! We have the scheme up and running at the maximum speed, we are all set up!

    Best Regards,

    Arnaud