K64 as Ethernet Switch or Dual MAC MDIO Dual PHY Controller?

[mignacio]

Hi,

(This was started from previous separate thread on K64 with ESP8266 wifi module: Use K64 with ESP8266 wifi module )

I'm still in research stage and I found K64 as the main and only NXP MCU SoC that supports Ethernet MAC but it needs a partner PHY transceiver controller, e.g. Micrel KSZ8081RNACA, as provided on its FRDM-K64 evaluation board.

* If I select the LQFP144 K64 package, I note there's only 1 set of PHY manager lines, MDIO / MDC to interface to PHY transceiver controller.

My goals are which I'm asking about here if they are possible or not;  please verify if these notes are correct or not?

* program K64 for 10/100 Mbps MAC Ethernet communication

* program as port 502 for Modbus TCP/IP master/slave communication

* for data security, I need K64 to support 2 separate nodes (or subnets) or physical ports (different IP addresses) such that data from one node is protected from being easily accessed by the other node unless it is intentionally routed to do so

* to separate the nodes, my original thought was to use the K64 as an ethernet switch controller but upon further studies IN GENERAL of MAC <----> PHY interface, (please verify if correct?) I found that in switch mode the same data are "shared" between 2 ports that have THE SAME IP address.  Any suggestion how I can separate and protect data access in one port from access by the other port in "switching" method using 1 MAC controller?

* after further reading, I thought of using K64, if possible in "DUAL" MAC mode with a single MDIO manager to interface to 2 PHY transceiver?  Is that possible with a single K64 chip?  Or do I need to use 2 separate K64s on same or separate custom board(s)?

* and from general reading and understanding of MII / RMII interface, I see that the K64 has 4 TX lines and 4 RX lines for either MII or RMII interface.  Does this mean that the K64 MAC controller can interface to 4 PHY controller ports?  But what operation mode would it be?  to switch / share TX/RX data across 4 PHY ports? or can I "fake-out" a dual/quadruple PHY unique addressable port in firmware maybe?

Please advise.

Thank you.

MI

[mignacio]

Here's the plan for purchase, prototype development & debugging efficacies:

1) For Base Central Controller need dual ethernet capable MCU RT1064 based:

   MIMXRT1060-EVK evaluation board:  use onboard MAC-PHY-MAG for 1st ENET

2) For 2nd MAC-PHY-MAG ethernet,  I'm looking into 2 options - both interface via SPI:

  a.  Wiznet Wiz810SMJ -  interface via available SPI lines to FRDM-K64 (~2 MHz max speed)

  b.  Adafruit Ethernet FeatherWing  

3) For WiFi module eval board:  need help SELECTING among these Wiznet eval boards with SPI lines for connecting to FRDM-K64 

   a.  WizFi360-EVB-MINI

   b.  WizFi120-EVB

   c.  WizFi210-EVB - via UART

   Or from Espressif slower UART interface: 

    d.  ESP8266-DevKitC

4)  Will use breadboard & jumper wires as necessary to connect with FRDM-K64

What else am I missing for complete hardware connections among all of those?  

Advice on power supply besides taking from FRDM Arduino-compatible headers?

Other comments, suggestions about 2nd Ethernet & the WiFi eval boards?

Please advise.

Thanks,

MI

[mignacio]

Hello,

Like I said originally, I need 2 physical Ethernet ports.  The 1064-EVK board has only 1. 

 It will not be cost effective to use 2 EVK boards for the product, the price doubles to almost $300 with many unused onboard extraneous peripherals we don't need.   

If I settle with this 1-ENET port EVK, I will need to build an "add-on" external CUSTOM board that "copies" the same circuitry of that 1st onboard ENET port (PHY & jack & all) for RT1064 to interface to a 2nd-ENET port.

I haven't checked the Arduino-compatible interface header pinouts if it will provide ALL the necessary pinout interface from the onboard RT1064 to go I/O to the external 2nd-ENET port on the custom board.

It's not so much about FCC regulatory certification, but that custom 2nd ENET port board will need to be designed properly according to PCB application notes (which I need to search for) to follow all hardware trace structures to prevent interferences, signal TX/RX, noise on the traces, etc. Designer may try to just copy exactly THE SAME layout of how the 1st-ENET port is on EVK board but communication electrical signals may still have errors and failures.

Basically, I'm worried about those other boards that I have to interface to the EVK because the EVK is deficient in what I need for the product.

So eventually, a custom board may be the best option after I first prove that the single-ENET port on EVK board works & I can do Ethernet operations that I need for RT1064 to do.

Anyone has comments?

Thanks for your help.

MI

[mjbcswitzerland]

Hi

The 1064EVB doesn't have all of the required ENET2 signals on its Arduino pins so the only option is a custom board for dual Ethernet.
A board cost of about $25 is realistic and so using 2 x EVBS for $300 would never make sense.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mignacio]

Thanks, Mark.

I tried but I guess I may be settling with i.MX RT1064, not the RT1062, because 1064 has built-in internal flash memory.  The only thing is even though it features dual Ethernet the eval 1064-EVK board only has 1 Ethernet RJ45.

The EVK costs $137.   The other options which are obsoleted and unsupported under MCUXpresso IDE have dual ethernet included on their eval boards.   With limited budget, I'm trying to avoid proposing to make a custom board even though it maybe cheaper in the long run, it could be very tricky hardware-wise due to all the requirements for PCB traces signaling and electrical standards, and such, where we don't have a in-house electronics hardware engineer to do it for us, including the need for FCC and other regulatory certifications.

Any thoughts?

MI

[mjbcswitzerland]

Hi

Unfortunately I know of no EVBs for the i.MX RT 106x with dual LAN - I suppose that there would be a small market for such a board as one otherwise needs to build a custom board. The same is however also true for the K66 if one wants dual-LAN - I have a few custom boards with various Kinetis parts and  three-port switch but none for i.MX RT at the moment (although I know of someone who is presently building one).

FCC is not relevant for EVBs since they are considered modules that could be used as part of a product but it is the complete product that is tested.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mignacio]

Mark,

I have not stopped at 1062...  

These are others I found that have 2 or more Ethernet MAC (some with PHY).   Some have expensive eval boards (need to consider instead of making our own custom board).

Question: Have you used before or looked into:

1) NXP MCF53017 with eval board M53015EVB: MCF5301X?  I don't see its own internal flash memory for firmware.

2) NXP i.MX287 with eval board MCIMX28EVKJ: MX28... 1 EMAC and 1 Fast Ethernet with PHY

3) (This one really looks ideal but is it obsoleted?)  MCF5441x but only has TWR-MCF5441X-KIT

… anything else?   I'm still searching.

And please forgive my ignorance but do you know exactly what the difference is between an evaluation/FRDM- board versus a tower/TWR- board?

Thanks for the help.

MI

[mjbcswitzerland]

Hi

1) is an old Coldfire V3 part (probably 20 years old) and peripherals are often older version (but compatible) with Kinetis. They need external memory and cost about $20 each so are not really for new developments.

2) i.MX287 is an application processor which is probably more suitable for running embedded Linux on and will need external memory resources.

3) Generally the Coldfire parts are obsolete and only used for maintenance of old products - my last Coldfire development was with the Kirin3 back in about 2012 (by chance a cable modem with a three port switch for two Ethernet connections) but they are too antiquated now and only really have old unsupported IDEs and development tools.

Freedom boards are practical, low cost evaluation/development boards.

TWR boards are awkward and expensive attempts of a modular system about 10 years ago : Almost impossible to follow signals around the back-planes between modules and impractical for most prototypes (FRDM boards are usually great for prototype of even for use as HW in small series) - of course the tower system concept won an innovation prize when it came out which shows that juries of such competitions never actually used or had to use them to find out how annoying they were..... If there is a FRDM use it and stay away from TWR kits....

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mignacio]

Hi Mark,

Thank you for the many different options to check-out.   I will definitely research on each one in order to see which will be best suited for our development and production needs.   As I stated on previous thread, I also need an MCU that can readily support WiFi  modules like the ESP8266.

And if I'm going to use an NXP MCU, I plan to develop all under MCUXpresso and use the corresponding available evaluation board (e.g. FRDM-K64) together with PEmicro Universal Multilink debugger USB interface together with Saleae Logic 8 Analyzer as I have done in the past embedded products.

I prefer to use actual eval-boards (not simulators) and hardware interface for sensors (e.g. temperature, humidity) in preparation to building our own custom board using the selected MCU and peripherals.

Before I saw your post today I found the KSZ8765CLX standalone ethernet switch which has 4/5 PHY ports and 4/5 MAC and I was trying to figure how I can interface this to the K64; I think I can do without the K64 MAC so then I need to choose a different MCU that can interface to it.

Besides all these ethernet, WiFi, ModBus TCP/IP even maybe a cellular modem for data communication LAN, WAN and out to the cloud, I need to interface with at least a temperature and a humidity sensor,  LEDs, while I need a debug port and a SWI programming port and such.

You can say, I like getting my hands dirty and trying to figure everything out from simple basic components and then going upward.   I don't like taking shortcuts and using someone else's code that I may not understand very well.   I like very much to understand what the product is doing exactly so when someone asks I can give thorough explanation how I did it, why I did it and if the boss wants some updates and changes, I would know to personally make the changes myself as possible.

Thanks again for your suggestions.   I'll definitely look into those different HW options.

MI

P.S.  Since a couple of hours ago of looking into option 2 with iMX RT1062 dual ethernet MAC crossover processor,  I think there is great potential in using this since it has a lot of GPIO and other features include its own temperature sensor and other protocol interfaces, e.g. UART, SPI,  that I can use.   

One concern is it is BGA packaging only which is a little more difficult as it can pose more surface mounting issues unless the PCB manufacturer provide high quality BGA mounting in manufacturing.

The other that is annoying to me is the lack of the normal "pinouts" tabulation for pin-by-pin I/O and function ALT-n assignments as I usually refer to when architecting the hardware-software interface design documentation that I provide to hardware electronics designer.   Neither the datasheet nor the reference manual has it.

Any comments?

[mjbcswitzerland]

Hi

The 1062 costs $3.48 in quantity - compared to >$7 for a K66 in quantity. It has 2 x HS USB and 2 x 100M Ethernet and operates at 600MHz and so it a more suitable choice when intensive communication is used and perfect for 2 port Ethernet without any trickery needed.

They have a strange GPIO/pin-mux concept that looks at each as internal PADs rather than external ports and takes some getting used to - see this video explaining it (once you get the idea it is about the same) https://www.youtube.com/watch?v=SmFTi8hlba0&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=29

The uTasker project includes also integrated 4G modem support via USB host but the K66 or i.MX RT are recommended since they have 480Mb/s HS USB and the K64 has only 12Mb/s FS USB that is also not that practical for host mode (the FS USB has only limited host capabilities). You can also plug an Android or Apple smart phone into the USB port to use as cellular modem connection if it is only needed sporadically. This is included as standard code for Kinetis and i.MX RT so needs no development when the uTasker project is used. For a development from scratch 2..3 months of time will need to be foreseen, so reviewing a working solution for a few days to be able to understand and modify it when needed usually makes more sense.

BGAs are quite standard now so only people who haven't used them before tend to be scared of them. If you prefer an LQF144 you can still take a 1021 with a three-port switch to do the same.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Hi MI

The K64 can interface to a single PHY/switch.

For your requirement you can use a 3-port switch like the KSZ8863 which allows tail-tagging mode to control operation on a frame-by-frame basis - to be in switch mode (the switch sends it to the port that its communication is on) or in single or dual-port mode (that is the firmware can specify which physical interface(s) the transmission takes place on). Each incoming frame is also tagged so that the firmware knows which physical interface it arrived on.
This results in a complete dual Ethernet port solution with a single MAC.

If you prefer a dual PHY solution you can choose an i.MX RT 1062 or 1064 instead since these have dual-MAC and so can use two independent PHYs (they are also faster and cheaper than a K64)

If you are just starting a professional product development I suggest you consider the uTasker project since it gives you immediate operation of multiple port/networked devices - see https://www.utasker.com/docs/uTasker/uTaskerNetworking.pdf with tail-tagging on any Kinetis or i.MX RT part (with code compatibility so one can develop on a K64 and switch to a faster i.MX RT part without any porting work).
- https://www.utasker.com/kinetis/FRDM-K64F.html
- https://www.utasker.com/iMX/RT1060.html

It includes a complete Modbus TCP solution as standard (for ASCII, RTU and TCP slave/masters): https://www.utasker.com/modbus.html

The operation can also take place via USB RNDIS (host or device).

Finally it allows simulating the complete operation on Kinetis or i.MX RT parts (see a reference tutorial at https://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis.pdf) so that all operations (including peripherals, interrupts, DMA and Ethernet) can be tested and debugged in approx. real time in visual Studio, thus making further product customising simple and efficient.

It has been using in industrial products using three-port Ethernet switches and Modbus since 2012 (on various Kinetis [and Coldfire V2] parts and in quantity - references available on request) so has a proven track record to ensure mission critical tasks with lowest development time and cost.

More documents, videos and features: https://www.utasker.com/docs/documentation.html

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]