ENC28J60 Click on PocketBeagle

I got the ENC28J60 Click module functioning fairly quickly but I wanted to share what I needed to do. Hopefully, it will help the next person who goes down this road.

I used these headers from Digi-Key: SAM1204-18-ND (https://www.digikey.com/product-detail/en/samtec-inc/SSQ-118-03-T-D/SAM1204-18-ND/1111842)

Ethernet Click Module: https://www.digikey.com/product-detail/en/mikroelektronika/MIKROE-971/1471-1320-ND/4495684

I am using Debian 9.1 2017-09-21

I had to update the bb-cape-overlays by using the following command. (In order for this to work you need to have an internet connection through the USB port. Go here for more info: http://ofitselfso.com/BeagleNotes/HowToConnectBeagleboneBlackToTheInternetViaUSB.php )

sudo apt update ; sudo apt install bb-cape-overlays

More info on mikroBus Click boards support can be found here: https://github.com/beagleboard/pocketbeagle/wiki/mikroBus%E2%84%A2-Click-Boards

I edited /boot/uEnv.txt to the following:
`

###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/PB-SPI0-ETH-CLICK.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
`

After reboot, it “just worked”!

My Download and Upload speeds from speedtest.net were about 2.7Mbit/sec. Not a speed demon but fast enough for IoT work.

Next step is to get a NimbeLink cellular modem working.

Steven:

Thanks for the report.

How do you get speedtest.net to report the Down and up speeds for a PocketBeagle?

— Graham

I installed speedtest-cli with this:

sudo apt install speedtest-cli

And ran it with this:

speedtest-cli

Steven:

Thanks for pointing out speedtest-cli.

I followed your tutorial and got my ETH-WIZ 10/100 Mbps Click running, since Robert released the overlay for that yesterday.

The one addition to your tutorial is that it also required upgrading the kernel to 4.9 as part of the install, per Robert’s instructions for the ETH-WIZ.

As you say, it boots, and just works.

Running speedtest-cli …
I get 3.3 Mbps down, and 4.6 Mbps up.

Confirmed that the chip had negotiated a 100 Mbps connection, so not the connection.

I note that, in reading the source for the ‘.dtbo’, that the SPI clock is set to 12 MHZ.
Recompiled the ‘.dtbo’ with SPI clock at 24 MHz.
Now, I get 3.8 Mbps down and 5.9 Mbps up, so the SPI transfer speed increase helps, but is not the bottleneck.

My network measures 71 down and 5.9 Up, so at least, I can max out my network connection on the uplink.

— Graham

How fast can you push the spi bus? I’ve just used the 12 mhz, as it was the default for one of the device tree in the docs…

Regards,

The possible bus frequencies are integer divisors of 48 MHz, so only option above 24 MHz is 48 MHz.
Spec on the W5500 chip says it will run up to 80 MHz.
So, I will recompile the ".dtbo’ for 48 and report.
— Graham

Yeah what Graham said. I seem to recall that the SPI bus could potentially
handle faster speeds too. But I've also read that above ~48Mhz the bus can
get noisy.

I recompiled the ‘.dtbo’ for 48 MHz SPI clock, which is the maximum for the Sitara.

Seems to work fine for a quick check.

Ran speedtest-cli, which moves a fair amount of data through it…

Download: 4.76 Mbit/s
Upload: 5.96 Mbit/s

Upload speed is probably constrained by my network, not the ETH-WIZ

— Graham

I wonder if there is away to measure the processor overhead between the ENC28 and the WIZ chip. Network thruput is not drastically different but curios which is most efficent use of processor.

The ENC28 has Max SPI clock of 20Mhz so if I understand Graham's explanation we could go up to 16Mhz on spi.

Additional notes:
When I got this first working I was using: Kernel Version 4.4.88

If you check: https://github.com/beagleboard/pocketbeagle/wiki/mikroBus™-Click-Boards
it will tell you which Kernel and Overlay versions you need for a given Click board.

You might need to upgrade your kernel using:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh
sudo reboot

See this for more info on kernel updating: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian

Hi Graham,

Has this survived the weekend? (any random loss of connection?)

I'm bumped it to 24Mhz by default, but would like to bump it again to 48Mhz..

Regards,

I have never seen it fail, but since the USB power goes off when my computer goes into deep sleep, it has never been run for more than a few hours at a time.

It is at home.

I’ll set it up on a permanent power supply and run it continuously for a few days, and report back

I think you also have a request from Steven to bump the SPI Clock on the ETH Click to 16 MHz.
I don’t have one of those to test.

— Graham

I have never seen it fail, but since the USB power goes off when my computer
goes into deep sleep, it has never been run for more than a few hours at a
time.

It is at home.

I'll set it up on a permanent power supply and run it continuously for a few
days, and report back

Yeah, then shortly mine locked up at 48Mhz... i'll leave it at 24Mhz
for now, and we will see how things go..

I think you also have a request from Steven to bump the SPI Clock on the ETH
Click to 16 MHz.
I don't have one of those to test.

Tested and bumped that to 16Mhz this morning. :wink:

Regards,

The ETH-WIZ locked up overnight running at 48 MHz SPI-Clock.

I moved it down to 24 MHz and rebooted. I’ll let it run for the rest of the week.

— Graham

The MAC address on this ETH-WIZ is unstable.

The original MAC address was the same Saturday through Tuesday, through many reboots and different image installations.

I updated the kernel tonight, and after rebooting, the ETH-WIZ appeared to stop working, but it turns out the MAC address had changed, so the PB was assigned a different IP address.

I then did another reboot, and it came up on a third MAC address (and another IP address assigned by the router.)

Another few reboots and a few power cycles, and it has not changed again, yet.

None of the three MAC addresses had a legitimate OUI.

So there is a random number generator somewhere making up MAC addresses (which is a violation of sorts of the MAC address assignment process.)
And so far, I have not figured out what triggers it.

So far, I have seen (as seen in ‘ifconfig’ and confirmed as being used on the network by the router)

86:37:73:45:44:E9
62:C0:73:03:5E:AD
FE:7F:41:5A:31:F9

This is weird. None of the three are in legitimate block assignments.

— Graham

I have been running my PocketBeagle with the ENC28 for over a week with no apparent issues. I have it sending/receiving data to a cloud-based MQTT server using node red. It sends a packet of data every 250ms and measures the time to get the data back. Average response time is about 30ms.

The device is just sitting on my desk and connecting through my home network to my Comcast cable internet. I have not tested any recovery from dropped connections, power fails, etc.

I have gotten an additional two MAC addresses (total five, now) presented by the ETH-WIZ.
(So, it has appeared on five different IP addresses in my network, and I can’t give it a static address, since that is paired with the MAC address.)

It never changes while running, and usually not when rebooting, but will almost always change the MAC address after loading a new image on the PB.
And none of them are ‘legal’. (That is, no recognizable OUI identifying the manufacturer.)

There must not be a memory for the MAC address in the ETH-WIZ, and the driver makes one up using a random number generator, upon booting on a new image for the first time.

I am tired of chasing this Ethernet interface all over my network address space.
.
— Graham

It appears that the ENC28 MAC address is random as well. It doesn’t show up with any vendor when doing an online MAC lookup. I wonder if it is possible to populate it with the same one that the USB Ethernet interface uses when attaching to a PC. I haven’t looked but my guess is there is a MAC address burned into the processor.

–steve

I have noticed that both of my PocketBeagles have unique MACs that do not move with the SD card when connecting via USB. (I tried switching the cards between PBs and the MACs stay with the boards. Could it be something in the onboard flash?

I meant in the onboard EEPROM…