STM32 ARM Ethernet Question

[rcbuck]

I have used the PIC18F57J60 chip in a couple of Ethernet projects in the past.

Now I want to learn how to use ARM for an Ethernet project. This will be a learning project for me. I have very little ARM experience. I did order a STM32F0Discovery board about 6 months ago. I was able to figure out how to write code to use the switch and LEDs that are on the board. After that I put it aside to work on other stuff.

I am going to order a board like this from Ebay:
http://www.ebay.com/itm/Stm32f4-Discovery-Stm32f407-Cortex-m4-Development-Board-st-link-V2-/321990090213?hash=item4af81adde5:g:ZAUAAOSwH3NXmzAm

and a PHY board like this:
http://www.ebay.com/itm/DP83848-Ethernet-Physical-Transceiver-RJ45-connector-control-interface-Board-Kit-/200924918291?hash=item2ec80ef213:g:9bAAAMXQaOVRlK3E

I would then use the System Workbench for STM32 and CubeMX tools to try to get these two items working. If I am able to do that, I would design my own board using a STM32F107RCT6 with the DP83848 part on board. The STM32F107RCT6 appears to be the lowest cost Ethernet ARM part. Plus it is available in a 64 pin package rather than having to use a 100 pin part.

Has anyone used the STM32F407 or STM32F107 in an Ethernet application using the System Workbench tools? If so, did the application libraries work from the start or did they require tweaking to make them work?

To start with, I will just be trying to get the Ethernet application to connect and obtain an IP address from my router. After that, I will see if I can send text to a Tera Term window. If I can make that work, the next step would be to have a simple web page that I could use to turn a couple of LEDs on and off.

Any suggestions or better solutions are appreciated.

[dgtl]

I have been using F107 and F207/217 with ethernet (usually with KSZ8081 phy, RMII mode; some others in MII mode too). The 4x7 is quite similar to 2x7. This was not done with system workbench, some of these designs have been done before SW was available and the rest carried on the same code. I've been using LwIP stack with raw api, wrote the eth driver for that myself. Before designing your own board, check errata too, there were some limitations when clocking phy directly from uc mco pin.

[rstofer]

This is only a suggestion:  The LPC1768 version of the mbed has everything you need for Ethernet except a MagJack.  Literally, you need to run 4 traces for the R+,R-,T+ and T- signals along with 2 more for the LEDs.  The library code has a complete TCP/IP stack based on lwIP.  You don't need to install a toolchain, you can use the web based tools.

This is a very fast way to implement TCP/IP.

FWIW, some STM32 boards are supported by mbed tools but i don't know anything about that.

https://developer.mbed.org/platforms/mbed-LPC1768/

I'm not interested in covering new ground.  When I wanted to build a network interface for an FPGA project, I just used the mbed.  Simple to code, known to work, no special tools...

[nctnico]

Still... how good is the LwIP code? For a project I'm currently working on (supposed to be mass produced eventually) I choose to use a Wiznet W5500 chip which does all the heavy lifting for me (basically a UDP + TCP/IP stack in a chip). I have not fired it up yet but my previous experience with uIP made me warry of using software UDP + TCP/IP stacks because of the many bugs in uIP.

[stj]

an ST Nucleo-144 board would be cheaper & most inclue ethernet onboard and usb-OTG too.
about $20 from Farnell / Element14

[rcbuck]

rstofer, thanks for the suggestion. I read several articles and blogs on the LPC1768. One thing I didn't like was having to use online programming tools. I prefer all of my code to be on my computer. The LPC1768 also requires a PHY chip like the STM32F part does. You can't just run 4 wires from the chip to a MagJack. That was the one advantage of the PIC part, no PHY chip required. You just come straight off of the chip to the MagJack.

I also read that lwIP had some issues. But I will keep it in mind if the STM32F path doesn't work out. It may be that the System Workbench Ethernet libraries also has issues.

As far as I know, the STM32F part is the only ARM chip in a 64 pin package with Ethernet built in. I will only be using 5 or 6 I/O ports on the chip so even 64 pins is overkill. You would think with the IoT supposedly going to take off like wildfire, someone would come out with a low pin count chip with maybe a dozen I/Os or so. Most IoT applications only control one or two pieces of hardware.

nctnico, I have looked at the W5500 and have been tempted to get one for testing purposes. The W5500 with a low pin count ARM chip would make a good combination. Hopefully your project will work out.

[rstofer]

Still... how good is the LwIP code? For a project I'm currently working on (supposed to be mass produced eventually) I choose to use a Wiznet W5500 chip which does all the heavy lifting for me (basically a UDP + TCP/IP stack in a chip). I have not fired it up yet but my previous experience with uIP made me warry of using software UDP + TCP/IP stacks because of the many bugs in uIP.

I used uIP on a project early on (LPC2106) with an external Ethernet chip/jack.  It worked well but, realistically, the 2106 wasn't a powerhouse.  lwIP is nothing like uIP.  The same author, sure, but entirely different.

The other free stack that I have used runs on a PIC32.  Microchip provides source.  My project was complete so I didn't play with this very much except to note that the code supports the Microchip WiFi chip.

I think a lot of it comes down to expectations.  Are we talking about a commercial project?  If so, buy a commercial stack.  Hobby?  lwIP will work nicely.  uIP will also work pretty well but it is limited to one packet in the air.  That's a pretty serious limitation.

[westfw]

The Phy to Microcontroller connection is one of those high-speed buses that I'm not sure you'd want to string between two boards.  Better to find an eval system that already has the Phy and magjack wired up.
Maybe a NUCLEO-F446ZE ?
Many vendors have cheap eval boards with an ethernet connector.
http://www.ti.com/tool/ek-tm4c1294xl
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/k-series-performance-m4/k6x-ethernet/nxp-freedom-development-platform-for-kinetis-k66-k65-and-k26-mcus:FRDM-K66F?lang_cd=en
https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware

[rstofer]

rstofer, thanks for the suggestion. I read several articles and blogs on the LPC1768. One thing I didn't like was having to use online programming tools. I prefer all of my code to be on my computer. The LPC1768 also requires a PHY chip like the STM32F part does. You can't just run 4 wires from the chip to a MagJack. That was the one advantage of the PIC part, no PHY chip required. You just come straight off of the chip to the MagJack.

See attached photo of MagJack on carrier board with mbed LPC1768

pinout:
https://developer.mbed.org/platforms/mbed-LPC1768/

I also read that lwIP had some issues. But I will keep it in mind if the STM32F path doesn't work out. It may be that the System Workbench Ethernet libraries also has issues.

Like many stacks, it requires your code to periodically service the incoming packets.  I used a superloop but I think FreeRTOS has done some work with lwIP.

As far as I know, the STM32F part is the only ARM chip in a 64 pin package with Ethernet built in. I will only be using 5 or 6 I/O ports on the chip so even 64 pins is overkill. You would think with the IoT supposedly going to take off like wildfire, someone would come out with a low pin count chip with maybe a dozen I/Os or so. Most IoT applications only control one or two pieces of hardware.

Right!  The LPC1768 is a 100 pin pkg.  I will almost always use the mbed 'stamp' format with a carrier board but I do lose quite a few pins that way.  Many other development boards do a similar thing.  Almost none bring out all the pins.

For IoT, the chip needs to do WiFi such that only an antenna is required.  That would be cool!

[rstofer]

One thing I didn't like was having to use online programming tools. I prefer all of my code to be on my computer.

There's no requirement that you use the online tools.  I like them because my code is 'out there somewhere' and I can get at it from any web browser, anywhere.  Another nice feature:  As things get updated, toolchain or libraries, you automatically have the latest and greatest.

I have downloaded my project, including the TCP/IP stack, and built it locally using Rowley Crossworks.  No problems!

[dgtl]

LwIP seems to be pretty much only free TCP stack that is used everywhere. Most of the uc vendors integrate it, mbed integrates it, etc. As with all bare metal and resource-optimized code, there can be issues when going to the bare minimum and running in low-memory conditions etc. For example, messing with buffer pool sizes can give you configurations, where there is not enough memory to work after some conditions and everything goes bad.
The performance depends a lot on what configuration is the stack used with. How many RX DMA buffers, how much memory for buffer pool. Increasing TCP MSS gives good results on throughput, but takes again much more memory and memory is one thing that uc-s typically lack.
Probably most of the issues happen in user code, because implementing a service on top of raw api can have quite lot of pitfalls. For example, proper handling of TCP abort (abort can come at any time, including before accepting connection etc). It took me a lot of debugging and testing to get everything right (espescially when programming a multi-connection service having quite high throughput). Another possible issue is a out-of-memory deadlock when the application gathers a lot of incoming data and does not free it until it gets a buffer to send out reply, but the memory is stuck in the incoming buffers. So definitely programming network stuff on embedded bare-metal platforms is much more difficult and error-prone than on desktop os-s.
A quirk i've patched out of lwip is the tcp out-of-memory connection priority handling. For some reason, they implemented it in a way, that in out-of-memory condition new incoming connection with SAME or higher priority is preferred. This means that if another connection comes into the same service and the system is low on memory, the previous connection that is being serviced is killed and buffers released. At some point, nothing gets done anymore, because services retrying will kill eachother. This happens in very low memory implementations only. After patching it out, my HTTP/1.0 server is able to respond >400 connections/sec of dynamic JSON system status on 48MHz STM32F107.
Pricewise, the STM32F107 + KSZ8081 has really good value and it is hard to beat; at the same time it still is cortex-m3. If it has enough processing power and memory for the task, then use it. I've used LPC1768 (and 69, 7x) too; they are also very good chips, better in most of the aspect, but not in the same price league as F107. If the product is higher volume and/or price sensitive, this can be a deal breaker. If your budget allows for higher end micro (for TCP, RAM memory is the first thing you run out of), go with it and don't waste your time trying to optimize and slim down everything. If you're planning to migrate down to F107, better start with F207 or F407 and then you can later on use the same know-how, tools and code on F107. Afaik, NXP does not have pricewise anything close.

[rstofer]

If the product is higher volume and/or price sensitive, this can be a deal breaker. If your budget allows for higher end micro (for TCP, RAM memory is the first thing you run out of), go with it and don't waste your time trying to optimize and slim down everything. If you're planning to migrate down to F107, better start with F207 or F407 and then you can later on use the same know-how, tools and code on F107. Afaik, NXP does not have pricewise anything close.

That price issue is often a primary consideration.  ALL of my projects are hobby grade.  I'm going to build exactly one device and I'm not terribly sensitive to component cost.  OTOH, I want the project to be achievable in short order by a single person, me.  When I see an opportunity to use a higher priced board that happens to have more functionality in the chip thus requiring less external support, I'm going to go for it.  If somebody else has already written most of the library code, I'm all in!

My contribution to my mbed project was to talk to the NVIC and implement interrupt driven SPI input to a large circular buffer (16k) in one of the separate memory blocks.  I used the other block as a packet assembly area for TCP output.  Pretty simple stuff.  I already had experience with the NVIC on the LPC2148.

From the TCP point of view, all my mbed had to do was make a connection to a print server and send a bunch of text.  Lots and lots of text.  It didn't have to receive any data for the application.  The networking code was done in an hour or so (learning curve) and the rest of the app in about a day.  It's been working well for over 5 years.  Never a glitch!

Interesting comments on using the lwIP stack and things to look out for.  I think I'll cut and paste the info into a permanent file.  Things to look out for.

lwIP is showing up everywhere.

[rcbuck]

See attached photo of MagJack on carrier board with mbed LPC1768

Yes, I saw that. But that is not a bare chip, the PHY chip is on the back of the carrier board.

I have downloaded my project, including the TCP/IP stack, and built it locally using Rowley Crossworks.

That is good to know. I may still look at the NXP stuff.

Afaik, NXP does not have pricewise anything close

I'm not planning on a commercial product so cost is not overly important. There is only about $2 (USD) difference in cost between the 107 and 407. The development board I will be using has a 407 on it. I just want to familiarize myself with the ARM parts and Ethernet.

Multiple connections will not be a problem as I will be using it in a one to one application. Unless I am reading something wrong, lwIP doesn't have HTTP as a component. I want to use HTTP for control of a couple of relays. Hopefully the TCPIP stack that the ST tools use has HTTP already built in.

lwIP is showing up everywhere

Interestingly, I had contacted Rowley last week about their compiler and their Ethernet library. This is the reply I received:
"We're not actively developing the Network product any more - the world has gone LWIP/FreeRTOS/mbed. So best that you go with the stuff that the silicon vendors are supplying."

[rstofer]

See attached photo of MagJack on carrier board with mbed LPC1768

Yes, I saw that. But that is not a bare chip, the PHY chip is on the back of the carrier board.

As I read the datasheet again, it seemed like the PHY would need to be external because only the MAC is inside the chip.  The schematic clearly shows the DP83848 PHY.  However, when I use the mbed, I deal with pins and from that point of view, the only thing I need to add is a MagJack.  To be honest, I have only looked at the underside of the mbed a couple of times and that was just in passing.  Out of sight, out of mind!

I guess if I were going to build a SBC, I would use the same chipset.  For my needs, a bare board implementation is unlikely.

I really am getting lazy...

[AdShea]

If you want a ready-to-go demo, I'd suggest the Olimex STM32 E407 board.  It's got one of the  144-pin chips, a PHY, and a magjack all ready to go. ChibiOS also ships demo code with LwIP for it.

[stj]

this link about covers it,
a practical walkthrough of a webserver on a Nucleo board.

http://www.carminenoviello.com/2016/01/22/getting-started-stm32-nucleo-f746zg/

[CM800]

Be careful with that board... It's the only dev board I've killed with ESD that I know of... I admit I'm careless in general about that, but it's one board that keeps dying on me.. 2 in a row!