W5100S, Independent LED Control over SPI Possible?

I’m using the W5100S on a project, and there are a few situations where I would like to take control of the LEDs directly over the SPI bus. Whenever I am using the ethernet functionality, I would let the LEDs to operate normally.

There is no mention of such an SPI command in the data sheet. Are there any undocumented commands that would let me take control of these LED output signals?

Thanks,
-Chris, The Stumbler
Sacheon, South Korea

Hello.

I didn’t understand exactly what you were talking about.

What is SPI used for? The SPI of the W5100S is connected to the MCU and used for Ethernet communication.

What are you going to use the LED for?

Your understanding is correct. The W5100S is connected to my MCU over SPI, for the purpose of Ethernet communication.

However, there is an edge case, which happens during boot-up where I have a secondary firmware boot loader available. That boot loader can use serial or Ethernet. Before my system officially begins to use Ethernet, I would like to use the LEDs to show information about my boot loader status. Once Ethernet is started, I would yield control of the LEDs to their normal Ethernet function.

That is a background on why I am interested in such a feature.

-Chris

So, any thoughts? Is there any technique I can use over the SPI bus to control the LEDs when the W5100S is not yet initialized as an Ethernet device?

In my opinion, it would be better to implement the application by reading the status register in W5100S than using SPI.

I am confused. The only interface between my MCU and the W5100S is the SPI bus.

Are you possibly saying that I can control the LEDs by writing to the Status Register?

The MCU and W5100S are currently connected via SPI. right?

And before you connect Ethernet, are you sure you’re going to control the LED with that SPI?
So you’re saying you’re going to implement it using an LED controller with SPI, rather than controlling the LED with a normal GPIO, right?

The situation seems too complicated.

I don’t understand exactly what kind of situation they use like this…

As mentioned above, before using W5100S, if you want to use SPI to express the MCU boot status with LEDs, you can modify the FW and use it that way.

There is a mechanism to change the FW inside the W5100S? I suppose I could take that approach, and then reload the normal FW after I am finished.

If the normal FW is available as source code, I would prefer to just modify to add a LED control register.

I have an existing design with no free MCU pins to control LEDs, which only needs any LEDs during a few seconds at boot time, before the W5100S becomes active as an Ethernet interface. If there was an LED control register, it would make my application a LOT easier. Otherwise I may need to change to a larger MCU, which has a lot of ripple-effects to the PCB size and the enclosure size.

-Chris

You cannot update the FW directly to the W5100S.

If you want to control your LED with SPI before you configure Ethernet, why don’t you control the LED before Ethernet Config on MCU FW?

Of course, that would be the normal and best way to do it. But as I said, I have an existing design (made before there was a secondary boot loader requirement) with no free pins on the MCU for LED control.

That’s why I was wondering if there was any undocumented registers to allow LED control over the SPI bus, maybe something you use during factory test procedures? Or maybe there is some way to “trick” the W5100S into a state(s) where it thinks it has a cable connection, data send / receive events, etc., are happening, and therefore indirectly control the LEDs that way?

-Chris

If the final answer is “No”, I would like to propose such a change to the interface definition for future chips.

Besides my unusual application, being able to control the LEDs directly would be very useful in automatic factory test procedures of assemblies that use the W5100S (and other WizNet Ethernet chips).

-Chris

Yes, there is no function you need.
Thank you.From the following development, we’ll produce it in consideration.