LPC2388 & KSZ8721 10Mbit problem

[mark]

Hi David

I don't remember any issues with ETHERNET on the Olimex board.

The only difference that I generally see between MII and RMII is the fact that it is necessary to set the EMAC to the correct speed (10M or 100M) after auto-negotiation (otherwise the PHY and EMAC may be set to different speeds and nothing works). This is sorted out by handling the PHY interrupt on auto-negotiation state change and using the speed read from the PHY to adjust the EMAC speed setting.

On all boards with MII this has never been necessary; even if there is no interrupt line the EMAC and PHY stay in sync at the appropriate speed. I suppose the additional lines (somehow) allow the information to be passed between the two and they sort this out themselves.

Regards

Mark

[SergeV]

I don't remember any issues with ETHERNET on the Olimex board.

Would you like to have one? I have it for you.

Trying to bring UDP up on raw LPC2378STK (using Windows + IAR + Jlink) I've found that program crashes as soon as EMAC power is switched on. Immediately after power on bit is set to "1" the debugger fails to show MAC registers content and Jlink driver hangs.
However uIP web server sample project worked fine (I can ping 192.168.0.100 and can see web page in a browser) and my first guess was that it was a problem of my code. However when I tried to step through this sample I've found the same problem exactly. The only difference is that when non-stop running the sample it "works", and my program does not.

What else.
This is my second Olimex LPC2378STK. On the first one I learned that problem exists, but ignored it since there was no clear signs about where it is (random rare hangs) and it did not stop the job. Well ..., did not until the LPC2378 controller died. I had nothing to do better than to replace the chip. After then the board worked for maybe a month, then died again and I purchased the second one.

Now I have one LPC2378STK dead and a second one half-live, but with clearly defined problem.
I'll try to study the case. But if somebody here could comment this or will take time to reproduce the problem...

[SergeV]

Sorry for this follow-up but I'm really upset. Please help.

Situation (listed above, but more precise):

Hardware: LPC2378STK(USB powered) + J-Link + IAR.
Firmware: Any. (In particular, say uip_webserver or LCD_demo)
After "Project Download and Debug" (Run to main, Hardware reset NXP/LPC)  I
* in the debugger window view Ethernet MAC registers - all OK
* in the debugger "Control block regs" window set PCONP.PCENET=1 manually (switch power On)
* go back to the Ethernet MAC registers registers: spoiled contents (many dashes etc.)
All this I do/see without program start.
Any ideas what could it be? Where to look?
---

What I did:
0) Read LPC2378 datasheet, UM, errata, forums (continue to) .. didn't help yet.

1) if I run uip_webserver it seems to work OK , but if I set a breakpoint there where PCONP.PCENET is set to "1", I see  the same problem. IAR reset (program restart) doesn't help (J-link fail to halt ARM core, etc). Debugger restart helps. Hardware reset button helps too.

2) I measured JTAG signals and LPC2378 power. All seem OK: signals within 3.3v limits, 3v3 and 1v8 power OK and stable.

3) measured 5v board supply current: 250mA, increases to 255mA if I switch EMAC power (make PCENET=1). Not too bad.

4) added 2uF cercap to 1.8V core supply. Nothing changed.

5) wrote this message... HTH
thanks.

[mark]

Hi

The first suggestions that I have that you could look at to be sure:

- 1) Make sure that the watchdog is disabled when debugging. This may be a general debug problem an not just an Ethernet problem (see http://www.utasker.com/docs/LPC23XX/uTaskerV1.4_LPC2XXX.PDF - page 19).

- 2) Are you checking the revision of the chip when configuring Ethernet?

    if (EMAC_MODULE_ID == OLD_MAC_MODULE_ID) {                           // if original silicon the RMII mode must be set with ETH_TX:CLK
        PINSEL2 |= (PINSEL2_P1_6_ENET_TX_CLK | PINSEL2_P1_0_ENET_TXD0 | PINSEL2_P1_1_ENET_TXD0 | PINSEL2_P1_4_ENET_TX_EN | PINSEL2_P1_8_ENET_CRS | PINSEL2_P1_9_ENET_RXD0 | PINSEL2_P1_10_ENET_RXD1 | PINSEL2_P1_14_ENET_RX_ER | PINSEL2_P1_15_ENET_REF_CLK);
    }
    else {                                                               // if newer silicon it may NOT be set
        PINSEL2 &= ~(PINSEL2_P1_6_ENET_TX_CLK);                          // ensure disabled
        PINSEL2 |= (PINSEL2_P1_0_ENET_TXD0 | PINSEL2_P1_1_ENET_TXD0 | PINSEL2_P1_4_ENET_TX_EN | PINSEL2_P1_8_ENET_CRS | PINSEL2_P1_9_ENET_RXD0 | PINSEL2_P1_10_ENET_RXD1 | PINSEL2_P1_14_ENET_RX_ER | PINSEL2_P1_15_ENET_REF_CLK);
    }


3) Have you tried putting your break point a few lines after you power up the Ethernet controller? Sometimes debuggers do have difficulties in certain code and running through it and stopping afterward may help. Eg. often it is not possible to step through PLL configurations.

4) The LPC23XX doesn't actually power down peripherals by default and so, if no other code is powering the EMAC down, there shouldn't be any need to power it up. On the other hand it shouldn't harm either - but maybe you could remove any powering down (presumably somewhere in the start-up code).

5) Have you tried the uTasker project code? This is supported here in detail but not other TCP/IP stacks.

Regards

Mark

[SergeV]

Hi Mark. Great comments. Thanks. (I'll study them carefully a bit later one-by one)
Now I have something to add (on what I did):

1) I replaced LPC2387 on my first Olimex board. This helped! It is working now.
Before it there was 3.3v Power supply shorted: ~2A current drawn. Reset button did not help.
Thus I (hope I) proved that LPC2387 on LPC2387-STK can be killed programmatically.
(This is a second LPC2387 chip replacement on this board and now I'm absolutely sure there was no other reason for chip to die other than long non-stop run. This is a last replacement too because the board is poor quality and will not withstand any more solderings)

2) I did what I asked to do: set a break at MAC power On instruction, did single step + view EMAC registers.
I have had the same error: registers' contents spoiled, debugger hangs, Reset helps!
The difference is that if I break few instructions after MAC power On, I can view regs and debug my code.
Thus I have 2 Olimex LPC2387-STK boards working, having the same problem, but this problem is fatal for EMAC debug on one board only.

3a) (routine job) Added 5Ohm ballast resistors to 3v3 IO power and cut off any 5V signals from the chip (I've found them 5) - in the hope to prevent chip from damage.
3b) (routine job) ordered LPC-P2378 board in the hope there will be no (or less) such a problems I had (have) with LPC2378-STK.

[SergeV]

- 2) Are you checking the revision of the chip when configuring Ethernet?
 if (EMAC_MODULE_ID == OLD_MAC_MODULE_ID) ...

Yes I do.
(actually, this has nothing common with my problem since Power has to be On first, any configuration afterwards)

3) Have you tried putting your break point a few lines after you power up the Ethernet controller?  

Yes. And this really helps with my LPC2378-STK board #1 (re-animated one).
On the second board I can set breakpoint, can step down the code, but cannot view EMAC registers.
As soon as I select IAR EMAC registers window Segger J-link debugger hangs (falls into infinite register reading loop). Debugger restart terminates this loop ... sometimes, but not always.

[SergeV]

4) The LPC23XX doesn't actually power down peripherals by default and so, if no other code is powering the EMAC down, there shouldn't be any need to power it up.

Nope, I humbly believe this is not true for EMAC.
Yes, most periferals come powered up after hard Reset, but EMAC power PCENET bit of the PCONP is "0" and power is off. Powerdown bit of the POWERDOWN EMAC register... Well, I'm not sure, probably is "0" too ("powered up"), I set it to "0" anyway, but this is of no problem.

5) Have you tried the uTasker project code? This is supported here in detail but not other TCP/IP stacks.

Not yet.
Submitted an application for the code.
(Actually I see the problem independent of the project: I upload any project, then turn EMAC power on manually, then open the EMAC registers page ...  Voila: hang.)
Thanks.

[SergeV]

- 1) Make sure that the watchdog is disabled when debugging. This may be a general debug problem an not just an Ethernet problem (see http://www.utasker.com/docs/LPC23XX/uTaskerV1.4_LPC2XXX.PDF - page 19).

Good paper.
I do not use LPC2378 watchdog.
What I did:
- uploaded my project to the LPC2378 (did not start it)
- turned EMAC power On manually
- opened Watchdog registers view debugger window
- made few steps forward - all ok. (I see WDMOD = 0 : not using watchdog)
- set break and run -- success.
- opened EMAC registers view window -- hang!

[mark]

Hi Sergei

You are right that the EMAC is not one of the peripherals that is powered up out of reset.
The reset state of the PCONP register is

    PCONP = (PCTIM0 | PCTIM1 | PCUART0 | PCUART1 | PCPWM0 | PCPWM1 | PCI2C0 | PCSPI | PCRTC | PCSSP1 | PCEMC | PCI2C1 | PCSSP0 | PCI2C2);

Therefore you do need to actively power it up.

Regards

Mark

[SergeV]

Hi Mark,

board (I just have my IAR one).

If you happen to play with your LPC2378+IAR could you please look at EMAC registers for me?
Just:
1) upload any project (do not run)
2) set PCONP.PCENET=1 manually
3) look at EMAC registers (open debugger window)
4) report result here.

I need to know if I'm unique having single problem on 2 boards..
Thanks in advance,
Sergei.

[mark]

Hi Sergei

Although it probably doesn't help much, I can confirm some differences in behavior between the Keil MCB2300 and Olimex LPC-2378-STK when using IAR (4.2 - this is quite an old version and doesn't 'know' the LPC23XX) and J-Link.

1). Generally I can't connect the debugger to the Olimex board without first switching the processor to boot mode. Then it works but I need to modify the register 0xe01fc040 manually to get it back to FLASH mode. I can't display the MAC registers since my IAR version doesn't know the peripherals involved but I can display the registers in memory at 0xffe00000. When the power is removed from the EMAC all addresses in this range display 0x00000000. When enabled only 8 long words are displayed (although there are more in the EMAC block) and the rest are displayed as non-accessible/non-existing. The code can however read and write these addresses. Although all works correctly when the board runs normally the code gets stuck trying to initialise the PHY - it waits for the PHY to become ready but this doesn't happen correctly. I don't know why though.

2). On the MCB2300 I don't have the same connection difficulties but I still need to manipulate the MEMMAP register. It seems as though the debugger switches it to 2. Strange but I have often used this technique so don't really think about it much.
In this case the same register display occurs. I can only see the 8 first long words in the EMAC block, but the code does work normally even when started with the debugger.

3). I repeated with CrossWorks 2.0 (still using J-Link) and this could display the EMAC registers normally and also it could see them normally in a memory window. It also showed the module to read all 0x00000000 when not powered but didn't display anything as non-accessible when not.

Although this may not help much nor explain your difficulties it does suggest a difference between the behavior on the two boards with IAR (at least with an older version). If the register view is causing a hang try also to view the registers directly in memory, since this may help.

Regards

Mark

[SergeV]

Mark, thanks. This helps.
Recently I ordered few more Olimex boards (This time them two are LPC-P2378).
Will continue to investigate the case whenever time permit to.
In the end I brought Ethernet/UDP up and have a lot to do with it leaving any hardware issues in the background.
(but I will. :-)

[HUD Engineer]

I'm not sure whether the following has any bearing on what you are investigating, but regarding the Micrel 8721, I've seen that there is a problem with 10MBit when using RMII.  If data for transmission is being transferred to the PHY via the RMII interface at just the same time as the first ethernet traffic is arriving at the receive port then the internal FIFO pointers that shuffle the RMII (2-bit wide) data back into MII (4-bit wide) can get corrupted.  The upshot is that sometimes the transmitted data on the wire is "out" by two bits.  The easiest way to observe this is the 2-bit shorter preamble, but keen observers will see their data followed by two spurious bits on the end of their message on the wire.

Depending on what PHY you then link to determines whether you are even aware of the problem or not.  Coupling to another Micrel PHY, or indeed just looping back masks the problem.  A short preamble should not be an issue, but an incomplete byte may be.  Some PHYs will simply allow each complete byte received to be forwarded, and aren't bothered that two extra bits are sent at the end of the message, while others will detect this and produce an unexpected extra byte on the received message which will then cause each and every message to be discarded downstream.

Once the fault mode has been entered, the PHY FIFOs need to be reset.  The best way to avoid the problem is to not send any data on the RMII for transmission until some data has already been received,since it is the start of data RX that triggers a FIFO reset, as best I can recall.

Regards