mbed

I have ported an LPC2138 project first to Mbed and now to my own PCB layout and it works fine. A Serial, Profibus industrial application. When I layed out the PCB I added the DP83848 48pin ethernet phy chip but it is only now I have built up a prototype. My ethernet test code works fime on the Mbed but not on my hardware. Like it doesn't even try to access the phy chip.

Question: Does the Mbed ethernet code only work on the Mbed hardware? I ask so as not to waste too much time on the wrong road. Is there a right road?

Hi Tim,

I've just added some additional details to the Ethernet page itself, as I think previously it only existed in the forum. See Ethernet:

Can you tell me if this solves your problem.

Still no life from my Ethernet interface lines. I'm no expert at C++ I just added the lines to the top of main(), is this what you meant? If I comment out the line - EthernetNetIf eth; - my code starts up, with it in it just hangs.

I2C i2c(P0_0, P0_1); Serial Terminal(USBTX, USBRX );

EthernetNetIf eth; TCPSocket tcpListen; TCPSocket* pConnectedSock;

---------- extern "C" void mbed_mac_address(char *mac) { mac[0] = 0x12; mac[1] = 0x34; mac[2] = 0x56; mac[3] = 0x78; mac[4] = 0x9a; mac[5] = 0xbc; } Tim

Hi Tim,

Yep, that was exactly what I meant.

I just did some experiments myself to confirm, and I get the results i'd expect. With the following code (and a special build of the interface firmware that allows me to turn it off), i get the following results:

#include "mbed.h"
#include "EthernetNetIf.h"

DigitalOut led1(LED1);
DigitalOut led2(LED2);
EthernetNetIf eth;

#if 1
extern "C" void mbed_mac_address(char *mac) { mac[0] = 0x12; mac[1] = 0x34; mac[2] = 0x56; mac[3] = 0x78; mac[4] = 0x9a; mac[5] = 0xbc; } 
#endif

#define USR_POWERDOWN    (0x104)
int semihost_powerdown() {
     uint32_t arg;
     return __semihost(USR_POWERDOWN, &arg); 
}

DigitalOut result(LED2);
int main() {
    // turn off interface, so it is like it wasn't there
    semihost_powerdown();
    led1 = 1;

    // setup ethernet
    eth.setup();
    led2 = 1;
}

With the mbed powered from VIN so the interface gets disabled when powerdown is called, with #if 0 led2 doesn't come on, and with #if 1, it does. So all looks in order.

I can't think of any other reason the software wouldn't work. Perhaps there is a difference in the hardware you've built? (different xtals, reset/enable lines etc?).

Simon

Simon, Yes me again. Still no joy with the ethernet chip. I have worn the words off the pages in the manuals and also checked my layout pin by pin as per the Prototype2production schematics, nothing. I firmly believe that the interface lines to the DP83843 Phy chip are not initialised, I am not getting that far! I LPC1768 manual does say if the 50MHz clock is missing it will hang but it is there on the right pin and in spec. My application is now just a few lines, works on MBED not on my hardware. Even changed the MAC address to the one my MBED is set to. Any Ideas?

#include "mbed.h"
#include "EthernetNetIf.h"

Serial Terminal(USBTX, USBRX ); 
  
EthernetNetIf eth;

extern "C" void mbed_mac_address(char *mac) { mac[0]=0x00; mac[1]=0x02; mac[2]=0xf7; mac[3]=0xf0; mac[4]=0x22; mac[5]=0x45; }

char mac[16];

//----------------------------------------------------
int main()
  { 
    Terminal.printf("hello World %f\r\n", 27.3);
    
    mbed_mac_address( mac ); 
    while(1) {
       Terminal.printf("mac address - %02x,%02x,%02x,%02x,%02x,%02x\r\n", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); 
    }
}

Simon,

Reading the LPC1768 manual there is a remark regarding initialising the Ethernet interface :-

Remark: when initializing the Ethernet block, it is important to first configure the PHY and insure that reference clocks (ENET_REF_CLK signal in RMII mode, or both ENET_RX_CLK and ENET_TX_CLK signals in MII mode) are present at the external pins and connected to the EMAC module (selecting the appropriate pins using the PINSEL registers) prior to continuing with Ethernet configuration. Otherwise the CPU can become locked and no further functionality will be possible. This will cause JTAG lose communication with the target, if debug mode is being used.

I get the feeling I'm stuck at the same place as there is no CPU activity on any CPU pins. Is there a chance I need to run some boot or magic code before the EthernetNetIF eth; line of code?

I'm not making progress here, is there any chance I could ask the guy who wrote this, Donatien Garnier I think his name is, if there is any catch in the code stopping me using my own hardware.

Hi Tim

Donatien's cookbook (note unsupported) contribution was a networking stack consisting of an lwip port along with a sockets implementation and some services (eg. http client and server) that make use of them. At the base of this stack, Donatien's code makes its Ethernet connection using the standard mbed Ethernet class, documented here in the handbook. If you want, you can see this in the use of the Ethernet class in the eth_drv.cpp source file.

If it were me having hardware Ethernet problems, I would eliminate the use of Donatien's code, and concentrate on getting Ethernet working directly eg. using the example on the handbook page you should see all broadcast frames eg. ARP requests (and have a link status of 1).

Regards
Daniel

Hi Daniel

Thanks for that I will try your different approach, always a good idea. I've just got hold of a LPCXpress board, guess what my simple code does not run there either. OK the PHY chip is different but I think it points to some little something on MBED that the code needs to see before it will startup.

Regards Tim

Correction: Code runs on the LPCXpress so looks more like my hardware.

Tim

Another frustrating day. I have concluded that I have a duff batch of LPC1768 chips here. The In-Circuit Programming works ok with Flash Magic (I think this runs off the internal clock though) simple serial programs run ok and the 12MHz oscillator starts. Anything that accesses the ethernet side of things makes the chip hang and the 12MHz oscillator doesn't start up, yes I have 50MHz on the ethernet clock pin. The RTC oscillator nevers starts up. I have changed the LPC1768 and my ethernet Phy chip - nothing. Now I'm waiting delivery on another batch of 1768's and will try them out. Unless someone has a better idea TI!

The next batch of 1768's arrived, they don't go either. So much for that idea. Surely someone out there has tried there own PCB design with ethernet. Help.

Try the LPC2000 Yahoo group, a lot of experienced people there.

Oh what a beautiful day. Found my problem, not hardware at all, it was BIN2HEX. Simple in the end, Flash Magic needs a .hex file and I've been converting the compiler .bin file with a very old (Intel8048 era) bin2hex utility. Even the simplest 'Hello World' application with the Ethernet libs fills 75K of code. So if anyone else is using In-System programming (ISP) and FlashMagic then the advice is, get an uptodate BIN2HEX and use the /4 option for either 24 or 32bit addressing range, not the standard 16bit range. Example 'bin2hex /4 test.bin test.hex'. And thank you everyone who reponded here.

Tim

Hi,i am new to MBED. and trying to work on some hardware controls(led,relay,motors) using networking based. help me regarding this.

manoj

Me too! I am a total n00b.

You could be interested in the new mbed official Ethernet Interface library.

You might be interested in a performance comparison of the new official networking library against the legacy one: Networking Libraries Benchmark

Cheers, Emilio