SPI hangs with CS low on Teensy 3.2 and WIZ820io example program

Status
Not open for further replies.

bboyes

Well-known member
Solved: SPI hangs with CS low on Teensy 3.2 and WIZ820io example program

Hi everyone

I'm working on a system using Teensy 3.2, a custom board, and the WIZ820io module. I'm testing using the DhcpAddressPrinter example, with few mods (mostly to add periodic output), Ethernet.begin() moved to setup() and Ethernet.maintain() moved to loop(). DHCP using an Asus RT-56NU router with the latest firmware and short DHCP lease time of 240 seconds to stress test the ability to keep a connection using Ethernet.maintain(). The net IP range is 192.168.1.xxx

This router is one of several I own or administer and it has been rock-solid since installed. It is the main office router and there is no reason to suspect it. It has a mix of fixed and dynamic IP space and that works fine on all the 10 or so other devices active on it at any given time (printers, multiple NAS, multiple computers).

The WIZ820io signals are the default SPI pins 10,11,12,13. WIZ820io reset comes from a system reset signal (DS3231M), which happens only on board power up.

Left it running this code overnight. It runs fine for 648905 seconds, a bit over 18 hours, then goes off the rails. Output is:
@64815 maintain was 2 rnw_cnt=564 << DHCP renewed OK, Ethernet.maintain() returned a value of 2, this is the 564th renewal
192.168.1.191
@64820 192.168.1.191
...
@64895 192.168.1.191 << All is well
@64900 255.2.0.0 << Ooops! How did this IP value happen?
@64905 0.0.0.0
@64910 0.0.0.0
@64915 0.0.0.0
@64920 0.0.129.85 << Things are really off the rails now
@64925 129.160.0.0
@64930 0.0.0.0 << execution hangs

DHCP renewed at 64815 seconds, the lease is 240 seconds but the router lets it renew in 50% of the lease time, 120 seconds (I don't know why but that is my observation with this router), which would be at 64935, but that never happened. The IP address got wonky at 64900, only 85 seconds after the last renewal.

Since the WIZnet module is getting the IP address from the Asus DHCP server I can't imagine where the bizarre values 0.0.129.85 and 129.160.0.0 originate.

Here's at least part of the smoking gun:
The processor is hung with SPI CS low (asserted). SPI SCK is also low and the system reset signal is high.

I looked at the SPI library in D:\arduino-1.6.3-TD1v25\hardware\teensy\avr\libraries\SPI

I wonder about the Ethernet library which actually supports the W5100 chip (right?) which is a subset of the W5200 used in the WIZ820io. Is there a reliable library which supports the extra features of the W5200?

The WIZ820io is not crashed. Just after this SPI hang I can still ping the WIZnet device, even long after the IP address should have expired it is still ping-able and still shows in the router client list. Finally after more than an hour the router has dropped it.

The first question would seem to be: what in the SPI library, or maybe Ethernet calls to it, could cause SPI to hang forever? At this point that might be an impossible question to answer without a trace of program execution prior to the crash (I wish there was a way to use JTAG debug adapters with Teensy).

In the SPI library I discover the actual SPI transfer cycles are not functions but inlined code in SPI.h, such as
Code:
	// Write to the SPI bus (MOSI pin) and also receive (MISO pin)
	inline static uint8_t transfer(uint8_t data) {
		SPI0_SR = SPI_SR_TCF;
		SPI0_PUSHR = data;
		while (!(SPI0_SR & SPI_SR_TCF)) ; // wait
		return SPI0_POPR;
	}
I can't tell where CS gets asserted and negated... or how much of the transfer is getting done by internal hardware and how much by the firmware driver.

Next question: is this some known issue with SPI and the Ethernet library?

Next question: do I need to drive the WIZ820io reset with a Teensy pin and periodically reset it?

Clearly this system needs a watchdog to keep this kind of hang from crashing the system, but also this kind of error should not be happening.

The system in which this will be installed must be reliable and run 24/7 for years. It is maintaining some environmental controls.

My belief/hope was that I would be way better off using known, tested libraries than to write my own. This could also be an issue with the WIZ820io hardware too.

I'll study the Ethernet library and the WIZ820io docs.

Thanks in advance for any insights into how to deal with this and make this Ethernet interface reliable... and keep Teensy from hanging.

Code:
/*
  DHCP-based IP printer
 
 This sketch uses the DHCP extensions to the Ethernet library
 to get an IP address via DHCP and print the address obtained.
 using an Arduino Wiznet Ethernet shield. 
 
 Circuit:
 * Ethernet shield attached to pins 10, 11, 12, 13
 
 created 12 April 2011
 modified 9 Apr 2012
 by Tom Igoe
 
 */

#include <SPI.h>
#include <Ethernet.h>

// Enter a MAC address for your controller below.
// Newer Ethernet shields have a MAC address printed on a sticker on the shield
uint8_t mac[] = {
  0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x02 };

// Initialize the Ethernet client library
// with the IP address and port of the server 
// that you want to connect to (port 80 is default for HTTP):
EthernetClient client;

// for measuring how long a routine takes
uint32_t time_start, time_stop;

uint32_t new_millis = 0;
uint32_t old_millis = 0;	// millis saved every tiem through loop, if new > old
uint32_t old_sec_millis;	// millis saved every second tick

uint32_t new_elapsed_seconds = 0;
uint32_t total_elapsed_seconds = 0;
boolean seconds_tick = false;

uint8_t seconds_five=0;
boolean seconds_five_tick = false;


void setup() {

	/*
	 * When using with PJRC wiz820 sd adapter
	 * https://www.pjrc.com/store/wiz820_sd_adaptor.html [sic]
	 * Some SD cards can be sensitive to SPI activity while the Ethernet library is initilized before the SD library.
	 * For best compatiblity with all SD cards, these 3 lines are recommended at the beginning of setup().
	 * Pins 4 and 10 will be reconfigured as outputs by the SD and Ethernet libraries. Making them input
	 * pullup mode before initialization guarantees neither device can respond to unintentional signals
	 * while the other is initialized.
	 */
	pinMode(4, INPUT_PULLUP);
	pinMode(10, INPUT_PULLUP);
	delay(1);  // allow time for both pins to reach 3.3V

	// Open serial communications and wait for port to open:
	Serial.begin(115200);

	//  Serial1.begin(9600);  // TX1, RX1 on Teensy pins 3 and 2, not the USB serial output!

	// Wait here for up to 10 seconds to see if we will use Serial Monitor, so output is not lost
	while((!Serial) && (millis()<10000));    // wait until serial monitor is open or timeout,
	Serial.println(millis());

	//  while((!Serial1) && (millis()<10000));    // wait until serial1 is open or timeout,
	//  Serial1.print('d');
	//  Serial1.println(millis());

	//  pinMode(12, INPUT);   // help make sure MISO is input to Teensy

	uint8_t flag=0, tries=1;

	  // start the Ethernet connection, try 8 times
	do
		{
		Serial.print("Try ");
		Serial.print(tries);
		Serial.print(":");
		flag = ethernet_start(mac);	// 0 if failed
		Serial.println(flag);
		}
	while ((tries++ < 5) && (flag == 0));

	if (0!=flag)
	{
		// Ethernet started OK
		Serial.print("Ethernet started after ");
	}
	else
	{
		Serial.print("Ethernet start failed even after ");
	}
	Serial.print(tries-1);	// loop already incremented it
	Serial.println(" attempts");

}	// end of setup

uint8_t renew;

uint32_t renew_count=0;

void loop()
{

	/**
	 * Are we at a 1-second tick?
	 * This relates only to time count
	 * No relation to treatment cycles, this is just time
	 */
	new_millis = millis();
	if (new_millis > (old_millis + 100UL))	// 100 msec or more has passed, so check for seconds tick
	{
		old_millis = new_millis;

		new_elapsed_seconds = new_millis/1000UL;
		if (new_elapsed_seconds > total_elapsed_seconds)
		{
			// seconds tick
			total_elapsed_seconds = new_elapsed_seconds;
//			Serial.print("@");
//			Serial.print(new_millis);
//			Serial.print(":");
//			Serial.print(new_millis-old_sec_millis);
//			Serial.print(F(" TES="));
//			Serial.print(total_elapsed_seconds);
//			Serial.print(" ");
			old_sec_millis = new_millis;
			seconds_tick = true;
		}
	}


	/**
	 * Do whatever needs to happen every second
	 * such as update other slower counters
	 */
	if (seconds_tick)
	{
		seconds_tick = false;	// we've used it up

		if (0 == (total_elapsed_seconds % 5))
		{
			seconds_five_tick = true;
		}
	}

	/**
	 * Do 5-second items
	 */
	if (seconds_five_tick)
	{
		seconds_five_tick = false;	// we've used it up
		Serial.print("@");
		Serial.print(total_elapsed_seconds);
		Serial.print(" ");

		/**
		* try to renew DHCP, maintain() returns
		* 0: nothing happened
		* 1: renew failed
		* 2: renew success
		* 3: rebind fail
		* 4: rebind success
		*
		* @see https://www.arduino.cc/en/Reference/EthernetMaintain
		*/
		renew = Ethernet.maintain();
		if (0 != renew)
		{
			renew_count++;
			Serial.print("maintain was ");
			Serial.print(renew);
			if (renew_count > 0)
			{
				Serial.print(" rnw_cnt=");
				Serial.print(renew_count);
			}
			Serial.println();
		}


		// print local IP address:
		//  Serial.print("My IP address: ");
		//  Serial1.print('d'); // start of message to LCD must be 'd' char
		//  Serial1.print("IP:");
		for (byte thisByte = 0; thisByte < 4; thisByte++) {
			// print the value of each byte of the IP address:
			Serial.print(Ethernet.localIP()[thisByte], DEC);
			if (thisByte < 3) Serial.print(".");  // don't print trailing period
		}
		Serial.println();

	}
}

/**
 * Try to begin ethernet with mac value, which means using DHCP.
 *
 * For non-DHCP different constructor with GW, etc is used.
 * @see https://www.arduino.cc/en/Reference/Ethernet
 * @return 0 if failed, 1 if success
 */
int8_t ethernet_start (uint8_t mac[])
{
	int8_t status = 0;	// 0 = failed
	time_start = millis();
	status = Ethernet.begin(mac);
	time_stop = millis();
	Serial.println();

	if (0==status)
	{
		Serial.print("Failed Ethernet DHCP after ");
	}
	else
	{
		Serial.print("OK Ethernet DHCP after ");
	}
	Serial.print(time_stop-time_start);
	Serial.println(" msec");
	return status;
}
 
Last edited:
Did you connect the W5200 reset to pin 9 ?

The W5200 absolutely requires a reset pulse. It powers up in an invalid mode where it drives MISO, even if CS is high. Not nice. It doesn't play well with other SPI devices until it's had the reset pin low.

We recently redesigned the WIZ820+SD board to have a reset chip, so things will always automatically work even if you don't initialize or reset the W5200. Of course, if you just drive pin 9 low (as recommended on that page), or start the Ethernet library before the SD library, things work fine. But without a reset, the W5200 is a little disruptive monster!
 
Last edited:
The only other thing I could add is that for me the combo of WIZ820io an Teensy have proven to be extremely reliable. I've installed one in my house the has run non-stop for years without problems and one at a customer for 8 month running non-stop in conjunction with Teensy 3.0.
 
Well, some more oddness. With the scope left on the CS and SCK lines, CS goes low and stays low, often for the 5 seconds between when if (seconds_five_tick) is true. That might not be a technical violation of SPI protocol but neither is it a good idea... I'm really surprised to see this behavior. I didn't notice it originally since my main loop was calling Ethernet.maintain() much more frequently, like every 200 msec or so.
 
Yes, it is connected to ground through a 10K pulldown. Voltage on that pin is 0.001 volts.
 
The WIZ820io reset is tied to a reset chip, not pin 9 of Teensy. So it gets a reset when the whole board powers up, which might not be that often. IS that enough? I guess that depends on how often I call Ethernet.begin()... which should be...?

When does the Teensy Ethernet library drive that pin? Only during Ethernet.begin()? I'm only calling that once, in setup. The Arduino reference documentation is not at all clear on exactly what begin() and maintain() do, other than to say to call maintain() at least once per second. At the moment I am doing it every five seconds. But since the router (well, this router, anyway) permits a renewal at least 60 seconds prior to lease expiration, that should be OK.
 
CS goes low and stays low, often for the 5 seconds between when if (seconds_five_tick) is true. That might not be a technical violation of SPI protocol but neither is it a good idea... I'm really surprised to see this behavior.

Let's talk of the library's behavior on known-good hardware.

Or if we're going to talk of what it does on defective hardware, let's wait until the exact nature of the defect is known and reproducible!
 
Well, that is good to know since it implies there is hope... how often do you call Ethernet.begin()? Is the Wiz reset input tied to Teensy pin 9? (where is that documented that pin 9 is the one?). How often do you call maintain()?
Thanks...
 
Did you connect the W5200 reset to pin 9 ?

The W5200 absolutely requires a reset pulse. It powers up in an invalid mode where it drives MISO, even if CS is high. Not nice. It doesn't play well with other SPI devices until it's had the reset pin low.

We recently redesigned the WIZ820+SD board to have a reset chip, so things will always automatically work even if you don't initialize or reset the W5200. Of course, if you just drive pin 9 low (as recommended on that page), or start the Ethernet library before the SD library, things work fine. But without a reset, the W5200 is a little disruptive monster!

I have a couple of your WIZ820io adapters, the version prior to the reset chip, I think. I can go back to running some test code on them and see when reset gets asserted and also when and for how long CS stays low. I'll go try that right now and report back.
 
OK, I am running on just a Teensy 3.2 with WIZnet 820io and PJRC adapter board. I can see a 2 msec reset pulse to the WIZ module.

It's wonky, still, and gets that way faster than before. I am powering just via USB, and voltage on the Teensy power pin is 4.8 volts, technically enough, but I will add an external 5V supply... done... now the voltage on Teensy is 5.1 volts.

SPI CS is still low for very long times.

Execution fails pretty quickly. SPI CS is low. Here is the serial debug output:
@45 192.168.1.191
@50 192.168.1.191
@55 192.168.1.191
@60 255.255.255.255
@65 255.255.255.255
@70 255.255.255.255
.....
@120 255.255.255.255
@125 255.255.255.255
@130 maintain was 1 rnw_cnt=1
255.255.255.255
@135 255.255.255.255
@140 255.255.255.255

what am I doing wrong? There must be something in my code or the library versions or ???

Thanks for the quick replies, Paul and Headroom!
 
I swapped Wiznet 820io adapters... these were purchased direct from the Wiznet site. I'm back to the 820io which was plugged into my custom board. CS to the Wiznet stays low for hundreds of msec with bursts of SPI clock.

It's failing after a few minutes:
@360 192.168.1.191
@365 maintain was 2 rnw_cnt=3
192.168.1.191
@370 192.168.1.191
@375 192.168.1.191
@380 192.168.1.191
@385 192.168.1.191
@390 192.168.1.191
@395 192.168.1.191
@400 192.168.1.191
@405 255.2.0.0
@410 0.0.0.0
@415 0.0.0.0
@420 0.0.0.0
@425 0.0.129.85
@430 129.160.0.0
@435 0.0.0.0
@440 0.0.0.0
@445 0.0.0.0
 
Some more data. Confirming there is a 1 msec reset pulse to the Wiznet. Just prior to reset asserting low, there are two SPI cycles to the Wiznet. Is this correct - accessing the chip prior to resetting it?

I changed the loop time to 1 second just so the SPI cycles are more frequent. It does appear that SPI CS idles low (asserted) with intermittent bursts of clock and data, in my case now once per second. Is this the intended SPI CS behavior?

Thanks
Bruce
 
Last edited:
Just prior to reset asserting low, there are two SPI cycles to the Wiznet. Is this correct - accessing the chip prior to resetting it?

Yes, it's trying to detect if you have a W5100 or W5200. The reset-less W5100 is tried first. If there's not a valid response, reset is pulsed, and then W5200 is tried.

You may believe the code is incorrect, but I can assure you it works on several W5100 and W5200 boards I have here. PJRC has sold a couple thousand those adaptors over the last few years to *many* different people. That's not an absolute guarantee the code is perfect, but I can assure you it's been very widely used and throughly tested.

The reset and chip select startup issues are well known. That's why we have the recommended code to put at the beginning of setup(), and why the new version was made so it would always work, even if that code isn't used and the SD card is initialized first. With the older board, simply use that code and it works well. It also works well without that code, if you have only the W5200 without the SD or other SPI.

If you've convinced there's a bug or wrong programming in the library, I'm happy to investigate. I've recently done quite a bit of optimization work on the ethernet library, so it's fresh in my mind and hardware is sitting on my desk right now. But like all problem reports, you have to follow the Forum Rule. Specific hardware and steps to reproduce the problem are required.
 
Last edited:
The pre-reset test makes sense... At this point I am trying to not assume anything. That's why I have gone back to just the Teensy, 820io adapter board from you, and the 820io module, running example code. Over this weekend I will try to make my test even more simpler: I can take out printing the IP address and just call Ethernet.maintain() as the only SPI transaction in loop().

I can go back to an earlier version of the libraries, though it looks like the basic Ethernet stuff has not changed much in a long time (it assumes the W5100, though there is no author or revision info in Ethernet.h or Ethernet.cpp in hardware\teensy\avr\libraries\Ethernet). The last SPI.h and SPI.cpp date (with you as one of the authors) maybe hasn't changed since 2014... it's hard to tell since there is no real versioning (is there?) of the individual library files - nothing in the files themselves, anyway. Maybe at Github.

I can also go back to a Uno board and Ethernet shield using the W5100 and see how the strobes work on that.

I wish I understood how the SPI works - I have written my own SPI and I2C in the past (in Java and assy code for AVR and 8051) and liked to put lots of comments in there, to help me think about what I was doing, to help me remember how it worked when I looked at the code a year later, and so our customers could follow along and modify it if they needed to. I'm puzzled why so much of the Arduino community code is not well-commented, or well-documented. I'm happy to contribute whatever comments and documentation I end up creating in this SPI and Ethernet quest. I appreciate the huge amount of work which others have put in to this - all the more reason it should be written to be maintainable and understandable by the masses of users who will consume it.

For example in SPI.h
Code:
	// Write to the SPI bus (MOSI pin) and also receive (MISO pin)
	inline static uint8_t transfer(uint8_t data) {
		SPDR = data;
		asm volatile("nop");
		while (!(SPSR & _BV(SPIF))) ; // wait
		return SPDR;
	}
Where does CS get asserted and negated: somewhere else?
What exactly is happening in
Code:
while (!(SPSR & _BV(SPIF))) ; // wait
how long can this wait? For what is it waiting? Could execution hang here forever?

I'll google around to see if there is more explanation about the workings of Ethernet, and try to sort through that source.

My interest is not academic. In my application, which will be installed in retail stores across the US, the Teensy will be periodically connecting to a "back office system" which is not running all the time. So I really need to understand what Ethernet.begin() does, how it handles exceptions, how I can make my code tolerate an ephemeral connection, etc. I'm not asking for any of that to be handed to me on a silver platter, just that the code be understandable (e.g. the coding standards used by Linux and the folks at Google who have hundreds of people who need to help maintain the code base).

So I will work on an even simpler test case, using just PJRC hardware and the Wiznet 820io and see what else I can learn. When I have something simple and reproducible I will post it here.

In the meantime it would be really great if you or anyone else could run the example listed above and look at the CS line with a scope and see at what level it idles.

I'm using Teensy because I think it's a great product. I have selected it for use on another project - a clinical treatment medical device which is now just starting into the first stages of FDA approval. There again, reliable operation is paramount, for obvious reasons. That device does not have Ethernet, it uses a 2.8" color touchscreen, and it has been rock solid in all the testing we've done thus far. I plan to open source the dynamically-generated GUI system I'm writing for that project.

Didn't mean to blather on... just wanted to justify my interest and explain my perspective. Perhaps it's interesting for you to know what your customers are doing with your hardware and software.

Thanks for the support, and if you can point me to any documents or code explanations I promise to read them carefully.

- Bruce

Yes, it's trying to detect if you have a W5100 or W5200. The reset-less W5100 is tried first. If there's not a valid response, reset is pulsed, and then W5200 is tried.

You may believe the code is incorrect, but I can assure you it works on several W5100 and W5200 boards I have here. PJRC has sold a couple thousand those adaptors over the last few years to *many* different people. That's not an absolute guarantee the code is perfect, but I can assure you it's been very widely used and throughly tested.

The reset and chip select startup issues are well known. That's why we have the recommended code to put at the beginning of setup(), and why the new version was made so it would always work, even if that code isn't used and the SD card is initialized first. With the older board, simply use that code and it works well. It also works well without that code, if you have only the W5200 without the SD or other SPI.

If you've convinced there's a bug or wrong programming in the library, I'm happy to investigate. I've recently done quite a bit of optimization work on the ethernet library, so it's fresh in my mind and hardware is sitting on my desk right now. But like all problem reports, you have to follow the Forum Rule. Specific hardware and steps to reproduce the problem are required.
 
Last edited:
maybe hasn't changed since 2014... it's hard to tell since there is no real versioning (is there?) of the individual library files - nothing in the files themselves, anyway. Maybe at Github.

Yes, on Github, you can find detailed history.

https://github.com/PaulStoffregen/Ethernet/commits/master

https://github.com/PaulStoffregen/SPI/commits/master

Like pretty much everyone else, I no longer maintain history in comments. That's a high maintenance & low reliability. Much better to let modern tools keep track of the history!
 
Here's a copy of the older (stable) version of w5100.cpp which ships with Teensyduino 1.27, with the fix applied. Just copy this to hardware/teensy/avr/libraries/Ethernet/utility, and it should solve the problem you're seeing.
 

Attachments

  • w5100.cpp
    9.3 KB · Views: 231
That fixes it - SPI CS now idling high/not-asserted

Here's a copy of the older (stable) version of w5100.cpp which ships with Teensyduino 1.27, with the fix applied. Just copy this to hardware/teensy/avr/libraries/Ethernet/utility, and it should solve the problem you're seeing.

YES, thanks! Just rebuilt and am testing now. SPI CS now correctly idles high. As you know, that bug would have allowed any other attempted SPI transactions to be seen by the 820io, with a clash of MISO signals and general badness as the 820io couldn't make sense out of SPI MOSI intended for another chip.

How hard was this to find? Thank so much for the quick fix!
 
Last edited:
W5200 reset and other things to make Ethernet super-reliable and self-healing?

Yes, it's trying to detect if you have a W5100 or W5200. The reset-less W5100 is tried first. If there's not a valid response, reset is pulsed, and then W5200 is tried.

So to make sure our hardware is 100% reliable, do we need a programmatic, pin-based hardware reset, or is a reset on power-up sufficient?
I've searched the W5200 errata V106E (which itself is confusing - it has seemingly random use of W5100, W5200 and W5300 to refer to the W5200) - nothing about reset there. The data sheet (V130E) only says:
This pin is active Low input to initialize or re-initialize W5200. RESET should be held at least 2us after low assert, and
wait for at least 150ms after high de-assert in order for PLL logic to be stable. Refer to RESET timing of “7 Electrical Specification”.

And the reset timing diagram just illustrates what the data sheet said in words.

If we do support a pin-driven reset, that apparently (I'm guessing) happens in the library as part of Ethernet.begin(), and does that ever need to be called other than at startup?

It appears that Ethernet.begin(mac) tries 16 times to get a DHCP address before failing, though there is no documentation of that at https://www.arduino.cc/en/Reference/EthernetBegin, nor is there advice about what to do if begin fails... or how to recover later. I can't just let my startup code hang forever, if the Ethernet cable is unplugged for example. It appears that Ethernet.maintain() will later make a successful DHCP binding, if the Ethernet cable is later plugged in, for example.

Others must have similar questions, I will also google around more to see if these issues have been written about elsewhere. Just in case I am making document which I will be happy to share.

Thanks!
 
Power draw value - only 200 mA including Ethernet

Another good data point: with a cheapo inline USB power meter, the combo of Teensy, PJRC adapter and WIZ820io only seems to draw 200 mA. That's perfectly OK to be powered just with the USB cable and lower draw than I was expecting. That's only 1W.
 
Last edited:
It's still working properly after over 30 hours (108,480 seconds), with DHCP renewal every 60 seconds - this is about 1440 times more often than normal, almost four year's worth in one day, for a pretty good stress test.
@108480 192.168.1.191
@108485 maintain was 2 rnw_cnt=1807
192.168.1.191
@108490 192.168.1.191

Thanks again for the quick support!
 
Sorry about reviving an old thread but... would like to register my unhappiness with the design decision to fix the pins for reset and CS in the .h files of the Ethernet module. Despite changing those two defines (and thank you, Paul, for including them in your version of Ethernet!) I have no luck so far.

Granted, I understand why it might be interesting for the folk who make these libraries to simplify things as much as possible, but in an ideal world, there would be a way for the user to assign alternate pins? I really would like to keep RX2/TX2 handy for things other than reset and CS for the Wiznet module...
 
Last edited:
Hi
Please forgive me if this is a trivial matter...
I have a Teensy/W820io running as a server on fixed IP. A client connects to it to send commands and extract info.
On occasion I get lockups where the client cannot connect or ping the Teensy server and a power cycle is required. Is there any way the Teensy can occasionally send a ping to test connectivity and perhaps reset the Wiz820.
thanks
John
 
Status
Not open for further replies.
Back
Top