MCF52259 & DP83640

[TheMnemonic]

Hi everyone,

i've got a DP83640 connected to my MCF52259. Now i've just want to ping my Device over the Ethernet. So I don't need any buffers. So I wrote the following code to initialize the FEC:

void Driver_TCP_IP_Init(){ MCF_GPIO_PTIPAR = 0xff;  //Enable all pins to Ethernet function MCF_GPIO_PTJPAR = 0xff;  //Enable all pins to Ethernet function   MCF_FEC_ECR = MCF_FEC_ECR_RESET;   while (MCF_FEC_ECR & MCF_FEC_ECR_RESET)   {      /* null */ ;   }/* Disable all FEC interrupts by clearing the EIMR Iterrupt Mask register */MCF_FEC_EIMR = 0x00000000; //no inerrupts needed! just to ping the dev/* Clear any interrupts by setting all bits in the EIR register */MCF_FEC_EIR = 0xFFFFFFFF;//TFWR (optional)/* Set the source mac address for the controller */MCF_FEC_PALR = (0  | (0x11 <<24)  | (0x22 <<16)  | (0x33 <<8)  | (0x44 <<0));MCF_FEC_PAUR = (0  | (0x55 <<24)  | (0x66 <<16)  | MCF_FEC_PAUR_TYPE(0x00008808));/* Initialize the hash table registers */MCF_FEC_IAUR = 0;MCF_FEC_IALR = 0;MCF_FEC_GALR=0xFFFFFFFF;MCF_FEC_GAUR=0xFFFFFFFF; //MII SPEEC 2.5MHz at maxMCF_FEC_MSCR=MCF_FEC_MSCR_MII_SPEED(16); // SYSCLK = 80MHz => 16 is this possible? According to the gudie 15 is the maximum!MCF_FEC_MIBC&=~MCF_FEC_MIBC_MIB_DISABLE;MCF_FEC_ECR |= MCF_FEC_ECR_ETHER_EN;MCF_FEC_RDAR=MCF_FEC_RDAR_R_DES_ACTIVE;MCF_FEC_TDAR=MCF_FEC_TDAR_X_DES_ACTIVE;}

Now the MCF stops working at line MCF_FEC_ECR |= MCF_FEC_ECR_ETHER_EN;

Does anyone know why? Further The MII Speed should be below 2.5MHz now since i've got 80MHz i need to set the MCF_FEC_MSCR_MII_SPEED to 16 but in the Gudie it is stated that it only supports values lower than 16! what do I have to do, to be able work with 80MHz?

thanks in advance!

regards

the mnemonic

[JimDon]

Could you clarify "stops working"?

[TheMnemonic]

well the MCF just hang. Unfortunately I have no possibility to Debug the MCF!

[mjbcswitzerland]

Hi

1) You are missing the configuration of the MDIO/MDC lines as peripheral (these default to IRQ lines and so need to be changed).

2) There is no RCR initialisation - normally the MII mode and a maximum frame length are set there, at least.

3) The maximum MII clock divide is 126 - the speed is BUS CLOCK /(2 x MII_SPEED value). to set 2.5MHz for 80MHz clock use a value of 16 for MII_SPEED (check the macro in the code to see whether it requires the real divide or the actual value).

Note that on the tower kit it is advisable to use a slower clock (800kHz is good) since the long bus lines and weak pull-ups cause a 2.5MHz signal to be filtered by the bus capacitance and this can otherwise fail at higher speeds.

Note that the MII clock needs only to be activated during MDIO transactions, avoiding a 2.5MHz clock signal being always present (saves power and reduces interferece). If you don't do any transactions you can leave it disabled.

4) I think that the main problem is that the buffer descriptors are not initialised and enabling the FEC operation causes the buffer descriptors to start polling and they cause an access violation which does lead to the debugger no longer operating. You need to point the buffer descriptors to SRAM so that the FEC can poll its memory there. In addition, you MUST ALSO give the FEC the rights to access the memory by enabling back-door access in SRAM by peripherals by setting the "back-door access" bit in the RAMBAR.

Regards

Mark

[TheMnemonic]

Hi Mark,

thanks for your answer. I configured my device according to your information. Now the mcf works fine.

But my Network still does not work. Now since I have a selfe made hardware, I'd like to check whether my hardware works correctly or not. Unfortunately I do not have an EVAL Board. So I was hoping that someone of you could tell me whether my hardware behave correctly so far.

Whats the state:

After I start up my device (ethernet already connected), the FDX LED on my SWITCH at the COLDFIRE port just Flashes a few times . The Configuration above will not change that state.

Is this a good sign? Does my hardware behave? What do I have to do, that also the 100/10M Led flashes?

Whats about the act_Led, link_led and the speed_led of the DP83640? At my board just the speed led is glowing, even if the ethernet isn't connected. Shouldnt they glow differentely?

thanks

Roman

[mjbcswitzerland]

Hi Roman

The PHY is not configured by your code and so the way that it behaves depends on the state of its STRAP inputs when it leaves its reset state.

You need to check the data sheet for the meaning of each of its STRAP inputs since the default operation of the chip is defined by these. The '0' or '1' state on these lines out of reset will set various modes, often also the bahaviour of its LED outputs.

You need to ensure that the state of these inputs is know and stable when the PHY's reset line is removed - since the lines are shared this often requires strong pull-up / pull-down resistors to ensure - they also have weak internal pull-ups / downs internally. In some cases the internal pull-ups on most of the M52259's GPIO can conflict and a technique often used to to drive these lines to the required state when the PHY's reset line is set by another port from '0' to '1') and then set them to the MII peripheral function afterwards.

If you can communicate with the PHY via the MDIO lines you can usually also overwrite the default settings, whereby the address of the PHY is also latched in via some of the STRAP inputs at reset ( in case fo doubt it is possible to poll all MDIO addresses - 1 to 31 - until it is found and then settings can be commanded).

Regards

Mark

[TheMnemonic]

Hi Mark,

Ok got that. My MCF and also the PHY are working now. For a further step I'd like to configure the IP, Gateway and also the Netmask of my device. Therefore I searched the FNET to find out how to do that. Unfortunately I wasnt successfull. So I have a few questions about that.

1. My PHY does have an IP address Register. But I cant find any further address Register for eg. Gateway and Netmask. Why?

2. Do I have to do all the IP and Gateway stuff in software? Or do I just have to configure the PHY (hardware) to do that?

3. What exactly do I have to do (cant work with the FNET Stack), to make my Device visible in the LAN?

Thanks.

regards

Roman

[mjbcswitzerland]

Hi Roman

The DP83640 is special since it includes some support for IEEE 1588 precision time protocol and therefore it can recognise some IP addresses belonging to this. For standard IP work it can be assumed that the PHY itself has nothing to do with the process.

That means that IPv4 / IPv6 is realised fully in software - the PHY does nothing in this respect. The net mask and gateway address are IP settings, which is at the software level above the Ethernet driver and slightly above the ARP software layer.

The FNET software will certainly do things that you want to do.

If you have difficulties you can also try the uTasker project since it will then also let you simulate the M52259, Ethernet and TCP/IP operation in real time on a Windows PC, which makes developments (and also learning) much more efficient than working on the board.

Regards

Mark

[TheMnemonic]

Hi Mark,

ok think I got the whole idea of the workflow.

I also started to build my own little stack which handels the whole connection stuff. I already have a working output (means I can send Gratuitous ARP requests which are seen and understand from other ethernet users in the same net). Unfortunately I got some problem with the input.

I prepared 4 Rx Descripors (same way I defined 2 Tx Descriptors (they working)) further I set the LOOP bit in the RCR Register.

For tests I write every second the Gratuitous ARP while in the mean time I check the input. Now I got the whole message back for the first 8 times. After that no more messages can be received.

I further changed the number of descriptors while I have to notice that I always can receive double the amount of the descriptor.

Do you know where my mistake is? Or do you might have a hint where I have to search?

Thanks

regards

Roman

[TheMnemonic]

Hi Mark,

sometimes you get blind even if the Failure is so clear!

Clearly missed the fact, that = RX_BD_E and |= RX_BD_E are not the same!! I now have a working LOOP... Unfortunately im still not able to receive any packages from the Ethernet yet. Will try that now.

Thanks anyway.

regards

Roman

[TheMnemonic]

Hi Mark,

have to ask again. I'm starting to go crazy! Did tripel check my code and still can't find the bug. Here is what causes the trouble:

After the FEC init (includeing the configuration of PLAR and PAUR) I send the Gratuitous ARP every secount once like I wrote before... in the mean time I check whether there has been a reception of a package.

(This whole thing works fine as long as I configured the RCR Register tobe in LOOP mode.)

Now if I disable the LOOP mode, I just rarely got an input. And if I got one the ERROR bit NO or CR are set.

Just for tests, I changed the IAUR and the IALR form 0x0 to 0xFFFFFFFF. This led to far more received packages but still all have eighter the NO or the CR bit flaged!

Since I really do not have a clue where to search the bug, I thought maybe you got an idea where I have to search.

Thanks.

regards

Roman

[mjbcswitzerland]

Roman

I would do the following:

1) Check that the receive buffer descriptors are all set up correctly (also the memory alignment according to the rules specified in the user's manual)

2) Ensure that the receiver is configured to accept broardcast frames (ff-ff-ff-ff-ff-ff).

3) Configure and enable the receive frame interrupt and put a break point in the receive interrupt routine. Also enable the receiver operation (including receive buffer descriptor polling).

4) Send a ping from the network - the broadcase sent frome the PC should be received and the receive interrupt triggered (probably there will be broadcast on the network which trigger it earlier too).

5) Now look at the content of the receive buffer descriptors to ensure that all is corect there (it should receive as many frames as there are buffer descriptors available) and also look at the message space to see the content of the received frame(s)

You may be able to identify what is and what is not operating correctly.

Regards

Mark

P.S. If you use the uTasker project you can also do the same in the uTasker simulator and compare what is the same and what is different to identify the root caue of any problems in your code.

[TheMnemonic]

Hi Mark,

thanks for your help, after no suggess with gudie, I build a Secound Hardware, put the same code on it and voila, everything is working now. Seems like I destroid my first DP83640 :-S.

Now I can receive and send ARP frames :smileyhappy:.

But there are still some questions left, which I'd like to ask you:

1. If I perform a Ping from my PC to the MCF, I got a reception. But if I analyse the data in the buffer, I have to notice, that about 3 out of 4 received Messages are bad. Means the frame exhibits failures. Is a rate of 75% rubish normal?? If not, do you think my Software is the problem or is it more likely that my harware exhibits some bad things??

2. What exactely is the IAUR and the IAlR Register for? And how exactly can I figure out how to set them with the CRC32 polynomial? Is there an example anywhere?

thanks,

regards

Roman

[mjbcswitzerland]

Hi Roman

In a LAN you should experience practically 0 error rate for Ethernet transfers. I would compare with an evaluation board since you will probably not be able to measure errors there. Use Wireshark to monitor the line since it will also show errored frames.

The only case where the error rate can be high is when working on a half-duplex connection configured incorrectly as a full-duplex one. In this case the colision detection will be disabled and the Ethernet controller will not back-off and repeat in case of collisions (collisions are normal occurrances in a LAN and increase with traffic). In this case you will however lose transmissions (they will simply be missing from any Ethernet recordings - like Wireshark) and not show up as corrupted frames.

You could also load a binary file containing Ethernet support from here: http://www.utasker.com/SW_Demos.html . If you get high error rate on your HW it would suggest that the HW is the problem. If it however runs reliably (you can ping it, FTP to it, access the web server or TELNET it) it would suggest that the SW is the problem.

The IAUR/IAIR registers are for configuring unicast hash addresses (and the GALR/GAUR are for configuring group hash addresses). You don't need to use these for your present work - just configure reception of broadcasts (ff-ff-ff-ff-ff-ff) and unicast (the MAC address of the interface). The hash registers should all be set to 0.

Below is an example of setting IPv6 group multicast as used by IPv6 neighbor discovery. This is as reference but you won't need it until doing advanced work.

Regards

Mark

// Configure a multicast address for IPV6 use//extern void fnConfigureMulticastIPV6(void){    #define CRC_POLY 0xedb88320                                          // CRC-32 polynomial in reverse direction    unsigned long ulCRC32 = 0xffffffff;                                  // set hash according to the multicast address 0x33 0x33 0xff XX XX XX (where XX XX XX are the last three bytes of the IPV6 IP address) as used by ND (neighbor discovery)    int i, bit;    unsigned char ucByte;    for (i = 0; i < MAC_LENGTH; i++) {        switch :smileyinfo: {        case 0:        case 1:            ucByte = 0x33;            break;        case 2:            ucByte = 0xff;            break;        default:            ucByte = network.ucOurIPV6[i + (IPV6_LENGTH - MAC_LENGTH)];            break;        }        for (bit = 0; bit < 8; bit++) {            if ((ulCRC32 ^ ucByte) & 1) {                ulCRC32 = (ulCRC32 >> 1) ^ CRC_POLY;            }            else {                ulCRC32 >>= 1;            }            ucByte >>= 1;        }    }    ulCRC32 >>= 26;                                                      // the upper 6 bits of the CRC32 determine the hash entry location    if (ulCRC32 < 32) {        GALR = (0x00000001 << ulCRC32);                                  // enter single group hash entry    }    else {        ulCRC32 -= 32;        GAUR = (0x00000001 << ulCRC32);    }    IALR = 0;                                                            // individual hash disabled    IAUR = 0;}

[TheMnemonic]

Hi Mark,

thanks for your fast reply. Downloaded a firmware from the uTasker and tried a ping and a telnet connection. Both worked fine and therefore I rechecked the buffer allocation... found the mistake there, didn't alligned the secound, third and forth rx buffer to 128-bit. :-S

Well now I have a working ethernet controller (thanks again for your support)... will now build my own little stack... "just" have to implement ethernet, arp, ip, icmp and UDP. Hope no bigger problems arise.

For the further use, I'd like to programm a unique MAC address to every controller at the time of flashing. This MAC shouldn't be changed by a further flashing of the same Device. Do you know if there is a UNIQUE number or ID in every ColdFire, which could be used for such an intend?

If there is no such possibility, do you have another idea of solving this problem?

Thanks

regards

Roman

[TomE]

http://www.maxim-ic.com/app-notes/index.mvp/id/186

Specifically:

http://www.maxim-ic.com/datasheet/index.mvp/id/3748

The above describes the Maxim DS2502-E48 chip, which contains a legal MAC address.

> For the further use, I'd like to programm a unique MAC address to every controller at the time of flashing.

Do you know you're meant to buy a "Company Unique identifier" from the IEEE? You can of course use "something random" with the risk of generating a duplicate MAC address to something else on the network. Using the Maxim chip gets you a legal address without that worry.

The only "tricky bit" is getting a one-wire protocol driver running so you can talk to it.

Otherwise you have to allocate some bytes somewhere in the FLASH in the chip somewhere, and have a way of initially setting that to the unique board Serial number or a MAC address. Then, whenever the software is updated in the part, the on-board or off-board programming software has to guarantee to save the old serial number before erasing the FLASH, and to put it back afterwards.

If you have multiple FLASH blocks and have a reason to run an EEPROM emulator in one of them, then you can save the serial number in there.

Of course if you have a reason to have an off-board SPI or I2C EEPROM then you can save it in there.

> "just" have to implement ethernet, arp, ip, icmp and UDP.

Why reinvent those wheels? Why reinvent all the 30 year old known networking bugs? Everybody who does this from scratch seems to get the same things wrong, time and time again.

At least have a look at FNET (one of the "Sticky Subjects" at the top of this forum). I've downloaded and looked at the code, and it is very good.

Tom

[mjbcswitzerland]

Hi Roman

The following gives some MAC details too: http://www.utasker.com/forum/index.php?topic=21.msg68#msg68

The Coldfire doesn't have any specific storage space for the MAC (like an OTP area which is offered by some chips) and I use a parameter system to manage the MAC of the board - this is a one time programmable operation but needs to be coordinated in some way (a company should carefully manage the use of MAC addresses from its allocated block and avoid duplicate addresses). I tend to use a one-time command via UART (the MAC can be used as a serial number for devices too) or settings via a web server: see http://demo.uTasker.com for an on-line device showing this; On the LAN page the LAN configuration can be set. The MAC address is initially 00-00-00-00-00-00 and can be changed once - then it is greyed (when no longer 00-00-00-00-00-00) so that it can no longer be changed (also the SW behind wouldn't accept a change). I use a parameter system based on a swap block (also contains lots more system parameters) based on two Flash sectors which ensures that no parameter (and the MAC) can be lost when parameters are modified, also when there are resets or power downs during Flash manipulation.

I have used the technique in Coldfires and other devices with small granularity flash for several years in a number of products and it has worked reliably and has been quite simple to manage (as I mentioned earlier it is usally necessary to have unique serial numbers in products - also for USB when this interface is also available - and by basing this on a MAC/serial number relationship makes it quite simple to maintain).

Regards

Mark