Powering down Ethernet PHY breaks debugging [LPC4088]

[bmcdonnell_ionx]

I need to power down the Ethernet PHY on my Embedded Artists' LPC4088QSB (QuickStart Board), in order to reduce the current draw. I've got some code which seems to do it, and reduces the current draw by (very) roughly 40 mA. But executing this code breaks debugging in a very strange way.

I'm using Mbed OS 5.7.5 in MCUXpresso. I describe further below how to check out and setup the project. But first I detail the issue.

Here is my test code where I demonstrate the issue:

GitHub - bmcdonnell-ionx/eth-dbg-issue 

Is this the right way to power down the PHY? Why is it breaking debugging, and how can I fix it? Details follow.

Problem Description

The problem goes like this:

• Once phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN); is called in main.cpp, and then after a reset or power-cycle, and after the code gets past the first for loop in ethernet_init(), you will no longer be able to debug. (i.e. The debugger can't halt the micro anymore, so you can't single step, "run to", or the like.)
  • This issue persists even after reset or power cycle. (Meaning you lose the ability to halt the micro once you pass that place inside ethernet_init().)
• The only way I've found to fix the issue is as follows:
  • Power cycle the board so that you'll be able to halt the micro again (initially).
  • Erase the micro flash.
  • Power cycle the board again.
  • Now you'll be able to debug normally - until you pass that phy_write() call again.

I tried debugging with the on-board debugger, and with a separate LPC-Link2; results were the same.

The issue presents itself in all three of the commits in the repository now. (If you use the most recent, you may need to change the place to "Stop on startup" in Run -> Debug Configurations... -> Debugger tab.)

Project Setup

Prerequisites:

• Git
• Python
• Mbed CLI
• MCUXpresso IDE

At the command prompt:

   mbed import https://github.com/bmcdonnell-ionx/eth-dbg-issue.git  

   cd eth-dbg-issue

   mbed export -m LPC4088 -i mcuxpresso

Alternatively,

   git clone https://github.com/bmcdonnell-ionx/eth-dbg-issue.git  

   cd eth-dbg-issue

   mbed deploy

   mbed export -m LPC4088 -i mcuxpresso

Then in MCUXpresso, import the project from the filesystem.

[jeremyzhou]

Hi Brendan McDonnell,

Thank you for your interest in NXP Semiconductor products and 

the opportunity to serve you.

Two suggestions:

1) You can force the PWR_DOWN/INT pin to low to put the device in power down mode instead of setting bit 11 (power down) in the basic mode control register, BMCR (0x00h).

2) Please give the following code a try.

//*****************************************************// 
//  Private functions                                  //
//*****************************************************//
void write_PHY (int PhyReg, int Value) {
  unsigned int tout;

    LPC_EMAC->MADR = (PHY_ADDRESS<<8) | PhyReg;
    LPC_EMAC->MWTD = Value;

    /* Wait utill operation completed */
    tout = 0;
    for (tout = 0; tout < MII_WR_TOUT; tout++) {
      if ((LPC_EMAC->MIND & MIND_BUSY) == 0) {
        break;
      }
    }
  
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Have a great day,

TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

jeremyzhou‌,

Do I understand correctly that your "two suggestions" are "either-or", meaning I would expect to use one or the other but not both?

1. I do not see any pins by the name "PWR_DOWN/INT" in the PHY (LAN8720) datasheet. Please specify which pin you're referring to by the name used there. Keep in mind not all the PHY pins are connected to GPIOs on the micro; refer to the LPC4088QSB schematic, page 3.

If you're referring to the Configuration Straps (section 3.7 of the datasheet), wouldn't I be creating a race condition if I try to use them? The reset pin on the PHY is tied to the reset pin on the micro, so I can't set the configuration straps and then reboot the PHY. I'd have to race to set the micro GPIOs ASAP on its startup before the PHY reads the config straps.

2. In your code, does PHY_ADDRESS == 1? If so, then I don't see any difference between your code and my code, except that mine returns a value indicating success/failure, and yours doesn't. Am I missing something?

[jeremyzhou]

Hi Brendan McDonnell,

Thanks for your reply.

Sorry, I made a mistake, as I refered to the PHY device: DP83848's datasheet.

To dig much deeper, I'll give a try to replicate the phenomenon later.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

jeremyzhou‌,

What have you found on this issue?

Please remove the "assumed answered" tag on this post. It is not.

I have a new problem now, too. When I power down the PHY with software / register writes (like this), then call Mbed OS's system_reset() (which calls NVIC_SystemReset()), the system hangs at the same place (here) as described above.

I don't have a work-around for this issue like I do for the one above (debugging), so this has become more pressing.

[jeremyzhou]

Hi Brendan McDonnell,

After several rounds of testing, I suspect that this issue is relative to the IDE, as the issue donesn't exist in IAR or KEIL.

I follow your describtion, reset the MCU after the MCU execute phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN);,

The MCU can stop at the breakpoints successful after the MCU is initialized.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

Jeremy, thanks for the follow-up.

What about the new issue I described?

bmcdonnell_ionx wrote:

...I have a new problem now, too. When I power down the PHY with software / register writes (like this), then call Mbed OS's system_reset() (which calls NVIC_SystemReset()), the system hangs at the same place (here) as described above.

-----

jeremyzhou wrote:

Hi Brendan McDonnell,

I suspect that this issue is relative to the IDE, as the issue donesn't exist in IAR or KEIL.

I follow your describtion, reset the MCU after the MCU execute phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN);,

The MCU can stop at the breakpoints successful after the MCU is initialized.

To reset the micro, were you using the reset button on the IDE debug mode toolbar, like I did?

Were you able to reproduce the issue in MCUXpresso? Did you use my Mbed project and export to IAR and Keil? Or did you use LPCOpen-based code of your own?

If it is an IDE problem, then that is still NXP's responsibility, as MCUXpresso is your product - right?

[jeremyzhou]

Hi Brendan McDonnell,

I've done the more testing with IAR and LPCXpresso IDE and let me demonstrate the testing result.

The demo code is periph_ethernet demo which is from the LPCOpen library, as I can test with different IDE and I'm not family with the Mbed OS 5.7.5. And the Eva board is LPC4088 OEM board and debug tool is LPC-Link 2.

In both of LPCXpresso and IAR IDE, the debug behavior will be lost when click restart button after executing the power down the PHY: LAN8720, as the Fig 1and Fig 2 show.

Fig 1

Fig 2

To recover the debug behavior, I should repower the board and external debugger, then breakpoint feature will become available, in another word, I've not encountered the issue like yours.

About the new issue you talked about, I can replicate the issue you describle, the debugger will lost its behavior during initializing the Ehternet module and PHY chip.

Fig 3

To recomever it, clicking terminate all debug sessions button to stop the current debug behavior, then start a new round of debugg.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

jeremyzhou wrote:

About the new issue you talked about, I can replicate the issue you describle, the debugger will lost its behavior during initializing the Ehternet module and PHY chip.

You have not understood the new issue. I don't just lose debugging connection. The microcontroller hangs. That is, following phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN) to power down the PHY, and then NVIC_SystemReset(), the micro never gets past LPC_EMAC->MAC1 = MAC1_PASS_ALL in the PHY initialization.

EDIT:

And the Eva board is LPC4088 OEM board and debug tool is LPC-Link 2.

As I said, I'm using the LPC4088 QuickStart board, not the OEM board. Does the OEM board use the same PHY as the QSB, and are all the connections between the PHY and the micro the same as the QSB?

I don't have an OEM board, so EA won't let me download the schematic to check for myself.

[jeremyzhou]

Hi Brendan McDonnell,

Thanks for your clarification.

I don't have the LPC4088 QuickStart board on hand, and in the OEM board, the PHY chip is LAN8720 (please checking the attachment),so I believe it's Okay to test with this board and I'd highly recommend you to do some testing with LPCOpen library on LPC4088 QuickStart board.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

Thanks for the schematic. The PHY circuits and connections to the micro look about the same, except for a few resistor values, and the diode network between the PHY and the Ethernet port on the QSB.

Did you try phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN) to power down the PHY, and then NVIC_SystemReset()? What was the result? Were you able to get through PHY initialization after the reset?

[jeremyzhou]

Hi Brendan McDonnell
The code running can't stop or be halted after executing the phy_write(PHY_REG_BMCR, PHY_BMCR_PWR_DOWN)  and NVIC_SystemReset(), it needs to click terminate all debug sessions button to recover(Fig 1).

                                                                    Fig 1
Then enter the debug model again, the code running can stop at breakpoints and be halted after initializing the external PHY.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

It seems you still don't understand my second/new issue, which has nothing to do with debugging.

Please share your test code with me so I can try to reproduce the issue with it. Please make a zip file including the whole projects, so I can import directly into MCUXpresso and build.

[jeremyzhou]

Hi Brendan McDonnell,

Please checking the attachment.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

Thanks for the code. I've modified it to demonstrate the "new problem" noted above. Please download my code (link below), build, program your target, and press the reset button on your board to let it run.

DO NOT DEBUG. Just program and run. If your OEM board behaves the same as my QSB, you will see that it executes everything through the NVIC_SystemReset() once, then resets, and gets stuck (hangs) inside Chip_ENET_Init().

GitHub - bmcdonnell-ionx/eth-power-down-issue-lpcopen

You may want to revert commit 1b3fb3f, in which I modified the board files.

(I think this is closer to the root cause of why we lost the debug connection. The whole system actually hangs.)

I think the problem has to do with running the Chip_ENET_Init() after Powerdown_PHY(). I don't think it's actually related to NVIC_SystemReset().

[jeremyzhou]

Hi Brendan McDonnell,

Thanks for your reply.

I'm able to replicate the phenomenon, the code will stuck in Chip_ENET_Init() after calling NVIC_SystemReset().

We'd like to recommend you use the WDT reset instead of software reset, and give a try.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

Jeremy, replacing NVIC_SystemReset() with WDT reset makes no difference, as demonstrated by the new wdt-reset branch of my code.

The reset is the reason I need to reinitialize the PHY, but it is apparently not the cause of the issue, as demonstrated by the new no-reset branch of my code.

Please advise on how I can power down and then safely re-initialize the PHY.

Thanks.

[jeremyzhou]

Hi Brendan McDonnell,

To implement it, in addition to the reset button, you need to add a hard reset trigger for LAN8720, as the Figure 1 illustrates.
As we know, the MCU will re-enter main.c after calling NVIC_SystemReset(), it's available to use a GPIO pin to emulate a Reset button to reset the LAN8702 before initializing it, as software reset doesn't pull know the reset pin.

Fig 1

And on page 59 in the datasheet, it demonstrates the boot process of LAN8720, it would help you to emulate the hardware reset.

Fig 2

Hope it helps.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

jeremyzhou wrote:

To implement it, in addition to the reset button, you need to add a hard reset trigger for LAN8720, as the Figure 1 illustrates.
...use a GPIO pin to emulate a Reset button to reset the LAN8702 before initializing it

So it can't be done with this board?

[jeremyzhou]

Hi Brendan McDonnell,

The Fig 1 seems like a ultimate solution, for the Embedded Artists' LPC4088QSB, it needs to remove the R2 prior to pull down the NRST pin, as in this way, the artificial reset trigger is effectless to the MCU.

Hope this is clear.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bmcdonnell_ionx]

jeremyzhou wrote:

...remove the R2 prior to pull down the NRST pin, as in this way, the artificial reset trigger is effectless to the MCU.

That does not address the issue. That would only prevent me from allowing the user to reset the MCU with a button press. It does not provide me with a way to resume communication between the MCU and the PHY.

On the LPC4088QSB, without any user intervention, after using the MCU to power down the PHY, how could I then do just one of the following options?

1. Resume communication between the MCU and PHY, so that I can execute the initialization sequence and power down command again.
2. Detect from the MCU that the PHY has been sent the power down command, without the memory that it has been sent. (It can't remember that because of the NVIC_SystemReset().)

Is this possible without hardware modification?