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.

DP83867IS: Problem : different “debugging methods” applied different initialization settings

Part Number: DP83867IS

Tool/software:

[What I want to ask]
PHYs(DP83867IS), implemented in prototypes of our product, is being evaluated.
We've designed and implemented DP83867IS to start operation with the desired initialization settings by accessing its registers.
However, on the debug phase, we've faced a problem with initialization settings applying differently depending on "debugging method".
In other words, the problem is that different “debugging methods” applied different initialization settings.
Please tell us how to solve this problem.

[Backgound]
We access to DP83867IS registers via MDIO communication, and using Gigabit Ethernet MAC "Core TSE", which is software IP from Microchip.

[Situation]
- Compiler we use is EWRISCV from IAR. (However, we think we can discuss debugging environments and methods in general terms.)
- In order to confirm the firmware design we implemented, When we run "Step execution" on the compiler,
  we can access registers without any problem after executing the register access function in that step execution.
- On the other hand, if the program is allowed to continue running from the entry point, without a breakpoint, i.e., without stopping the program, 
the behavior appears as if the PHY register is not being accessed.
- Specifically, after a Write access to a specific register in the DP83867IS, a Read back result to the same register said where the desired value was NOT being written.
- When a process was added in Test Procedure that would not allow the program to proceed if the desired value could not be read back,
  the process fell into an infinite loop, and the above event was judged to have occurred.
 
- I am concerned that when the implemented program is actually run in the real product, the operation will proceed without the desired PHY register access.
- I think that when the firmware and PHY are actually run in the product, there should be no "step execution".
Would you please tell me if there is a problem with the way the PHY registers are accessed or the initialization settings?

* Just for your information, If the write process is repeated until the correct value can be written or read back repeatedly until the desired value can be read back,
the process will be completed correctly after repeating these processes a certain number of times.

However, since we do NOT want to include these iterative processes in the real product,
and moreover, since it is difficult to provide a reasonable basis that such iterative processes can solve the problems shown in Situaion above,
e will leave this information as reference information.

  • Hi Asano-san, 

    Could you verify that the PHY is powered on and registers are accessed according to the following recommendation in the datasheet?



    Could you also verify that MDIO/MDC interface is sending data according to the following recommendation in the datasheet?



    If both specifications are within the recommendation, could you add delay function each register read/write access and run the entire script to see if all register values are initialized as it was intended to?

    Please let me know. 

    Best,
    J

  • Hi J-san,

    This is Asano typing.
    Thank you for your response every time.

    As you pointed out, we will check the timing during power-up and MDIO communication through waveform measurement.
    After that, depending on the result, we also trial inserting delay function for each Read/Write access.

    ### (Additional question No.1) ###
    - Where is the countermeasure “adding a delay function to each access” described in the datasheet,
       including the evidence for it?
    - If not, would please show us the reason for it as well?

    ### (Additional question No.2) ###

    Would you please let me know your perspective, if any,
    on the following phenomenon that I mentioned at the top of this thread?

     - If the write process is repeated until the correct value can be written or read back repeatedly
       until the desired value can be read back,
       the process will be completed correctly after repeating these processes a certain number of times.
     - Even if the program is allowed to continue running from the entry point, without a breakpoint,
       i.e., without stopping the program, the above phenomenon is occurred.

    From the occurrence of this phenomenon,
    we suspect that this problem is not a time factor such as delayed function insertion,
    but the number of repeated accesses is the essence of this problem.

    With respect to this one, is it possible that the setting is only fixed by repeated accesses?
    Or it can be set by a single access?

    Best Regards,
            Asano

  • Hi Asano-san, 

    ### (Additional question No.1) ###
    - Where is the countermeasure “adding a delay function to each access” described in the datasheet,
       including the evidence for it?

    Adding a delay function was my personal idea, not from the datasheet. 

    When we run "Step execution" on the compiler,
      we can access registers without any problem after executing the register access function in that step execution.
    - On the other hand, if the program is allowed to continue running from the entry point, without a breakpoint, i.e., without stopping the program, 
    the behavior appears as if the PHY register is not being accessed

    Based on this, I thought that maybe your MDIO is sending write commands too fast that the PHY is not taking the commands properly. Therefore, I suggested to put some artificial delay in the program so the program would wait some time before going into the next command. 


    Would you please let me know your perspective, if any,
    on the following phenomenon that I mentioned at the top of this thread?

     - If the write process is repeated until the correct value can be written or read back repeatedly
       until the desired value can be read back,
       the process will be completed correctly after repeating these processes a certain number of times.
     - Even if the program is allowed to continue running from the entry point, without a breakpoint,
       i.e., without stopping the program, the above phenomenon is occurred.

    From the occurrence of this phenomenon,
    we suspect that this problem is not a time factor such as delayed function insertion,
    but the number of repeated accesses is the essence of this problem.

    With respect to this one, is it possible that the setting is only fixed by repeated accesses?
    Or it can be set by a single access?

    No, this is not the expected behavior and should be set by single access. Could you check if the MDIO line has pull up resistor between 1.5k and 2.2k ohm, and ensure that MAC does not send out MDC signal over 25 MHz. In addition, please ensure that MDIO write command follows the following: 



    Please let me know how this goes. 

    Best,
    J

  • Dear J-san,

    This is Asano typing.
    Thank you for your kind suggestion to improve the problem.

    Since your reply, we have investigated output waveforms by the surrounding circuit blocks
    and found that hardware (FPGA) design (inc. understanding of GMAC IP) that controls MDIO access was incorrectly designed,
    so as to fail to manage MDIO communication completion detection (it was not detecting completion correctly)

    Therefore, we have corrected the design to correctly detect completion of MDIO communication before proceeding to the next instruction.
    The situation has been resolved (without inserting a delay function).

    We apologize for the inconvenience. This matter is now closed.
          Best Regards,