Anyone using K64F FRDM ethernet?

[EdSutter]

Has anyone successfully built/ran code that works with the Ethernet interface on the K64F-FRDM board?

I used the code out of the SDK as an example, but have not been able to receive (or send) any packets.

The best I can do is monitor link status on the RMII interface.

Any hints?  Has the Ethernet code that comes with the SDK been tested (I notice that there

are no examples using it)?

Tx

Ed

[EdSutter]

As a result of getting over this Ethernet hump, I was able to complete a basic port of uMon-M (http://www.umonfw.com) for the K64F-FRDM platform. This is an MCU (i.e. slimmed down) version of Micromonitor (uMon, a boot monitor I wrote years ago).  uMon is includes a very basic flash file system resident to the on-SOC flash and an environment that can be shared with the application (refer to the website for more information).  This allows you to write an application that can be installed via TFTP and access other files already in the flash.  I guess you could compare uMon to DOS (not sure if that's good or bad!) because it provides the basic environment onto which you can install and run your application.

Anyway, sooner or later I'll post the source to the site, I'm just cleaning it up at the moment.

Not really sure how practical this is for these smaller systems, but if you're interested let me know.

[LuisCasado]

Hello Ed,

You can use the MQX BSP for the FRDM-K64F.

Freescale MQX RTOS 4.1.0 for the FRDM-K64F   : Includes an RTOS, File System, TCP/IP and USB host/device software stacks. Does not require MQX™ 4.1 installation.
Size (K): 157830 Format: exe Rev #: 4_1_0_FRDM-K64F Modified: 4/2/2014

Regards,

Luis

[EdSutter]

Thanks Luis,

It appears that this doesn't use the code that comes with the SDK, is that true?

[LuisCasado]

Hi Ed,

No, it doesn't. SDK and MQX will be merged in future MQX/SDK versions. Now MQX 4.1 uses its own drivers.

Luis

[EdSutter]

Ok,

Do you happen to know if the Ethernet code in the SDK has been verified?

I'm suspicious for two reasons:

1. I'm basically using it, but can't send/receive a packet

2. There's no example using it under the apps directory of the sdk.

(I realize it is beta)

Tx

[LuisCasado]

Hi Ed,

I don't know if the ENET drivers have been tested.  Have you checked if there is release notes?

Best Regards,

[EdSutter]

Luis,

Yea, read through it.  Didn't see anything that indicated ENET didn't work.

Also note that I'm not making a claim that it is broken, I just haven't gotten it

to work; so knowing someone else did use it successfully is just a point of comfort

I'd like to have while I'm beating my head against this wall.  :-)

tx

[LuisCasado]

Hello,

Try to disable the MPU if you haven't done yet.

    BW_MPU_CESR_VLD(0);

And I assume, you have init the clock gate : clock_manager_set_gate(kClockModuleENET,0,true);

Luis

[EdSutter]

Luis,

Yes I did have the clock enabled; however was not aware of the need

to disable the MPU.  Doing that eliminates my EBERR and I receive a packet.

That's progress!  :-)

Thanks.

[mjbcswitzerland]

Ed

This is also needed by the USB controller when to get on to that...;-)

If you need Flash access (rather than just SRAM) you need to check the bus master access rights in FMC_PFAPR.

Regards

Mark

[EdSutter · Accepted solution]

Ok I got it...

Two issues:

1. I wasn't disabling the MPU

2. I was using enhanced buffer descriptors, but didn't have "Enhanced Framing" enabled.

Thanks folks!

Ed

[dave408]

Hi Ed, I am pretty new to the ARM world and am trying to use KDS with the FRDM-K64F board to send data over Ethernet.  I've been doing a lot of searching for instructions, and your post is the closest I've found to someone that has something working.

My current configuration is KDS 1.1.1, KSDK 1.0.0, and MQX for KSDK.  I've got a skeleton application that builds, and via Processor Expert I have added the SPI and ENET components.  The problem is, I have no idea where to go from here.  Were there any documents online that helped you get things going, and if so, would you mind pointing me to them?  Pretty much everything I have found is outdated (e.g. from 2009).

[EdSutter]

Dave,

Just keep digging.  I hunted quite a bit to get up to speed on these critters.  I did a little bit of work with a few of the M3-M4ish devices (not just freescale), so my knowledge base was somewhat distributed across the vendors.  The good news is that for the most part, these devices all boot the same way.  That's what I was interested in.  I didn't use any IDE, just downloaded the cross compiler from CodeSourcery, got to know the OpenSDA stuff and ran from there.  There's plenty of source code examples in the SDK. 

Not sure what you're looking to do, but if its of any help, I ported a version of my bootloader to a few of these devices (K64F included), that will at least give you a sample of some working applications.  This includes, aside from the bootloader, a few reasonably useful applications that run ontop (WebSockets http server, LUA, etc...).  That stuff is here: http://www.umonfw.com.  There are certainly other versions of this kind of stuff floating around too.

HTH

Ed

[mjbcswitzerland]

Ed

The uTasker project supports the FRDM-K64F:

New Freedom FRDM-K64F board

https://community.freescale.com/message/400457#400457

The Ethernet driver is compatible with other K parts with Ethernet.

The difference on the board is the KSZ8081RNA that it uses with a fixed PHY address of 0 - plus a slight (potential) complication of not having the PHY IRQ connected.

The PHY but it needs to be polled (due to lack of IRQ) to ensure that the EMAC's settings are synchronised to the line settings that the PHY auto-negotiates to to be absolutely sure (speed and duplex). Depending on how you default the EMAC it may be that there is no operation if the RCR settings are out (eg. PHY autonegotiates to 100M and the RDR is set to 10M by default).

Regards

Mark

[EdSutter]

Mark,

Thanks, I'll take a look there too..

I'm just trying to get a very basic (polled) Ethernet interface up using only the HAL stuff that comes with the SDK.

The PHY part of it seems to be working ok (I'm using PHY addr 0); I'm able to detect link state and poll waiting for

auto-negotiation to complete (it auto-negotiates to 100M, same as I have the MAC configured); however, after basic

setup of the interface I never see the buffer-descriptor's empty flag go inactive.

I recently noticed that my EBERR bit (EIR) goes active as soon as I set the ETHEREN bit (ECR); so I'm obviously

doing something wrong.

Ed

[mjbcswitzerland]

Ed

Have you ensured that all buffer descriptors and buffers are aligned in memory according to the EMAC's requirements (16 byte boundaries)? If not there will probabably be such errors.

Regards

Mark

[EdSutter]

Yep, verified all that.  All addresses (both the descriptors and the buffers pointed to by the descriptors) fall on 16-byte boundaries.

The reference manual talks about uDMA used with Ethernet.  Is there something in the DMA section that needs to be initialized for the EMAC?