Teensy 3.6 resetting with Serial + Wiz820 Ethernet

[MTA]

Hi all

I'm using Teensy 3.6 as a bridge between ethernet and uart devices. I'm using the Wiz820 Ethernet module with teensy 3.6 on a breadboard for a prototype (no Wiz820_sd adaptor)

I've connected the Wiz820 MISO/MOSI/SS/CLK/RST/VIN/GND just as shown in
https://www.pjrc.com/store/wiz820_sd_adaptor.html
and I'm using Ethernet library to communicate using UDP protocol.

Also I'm using Serial1 at 1500kbps to communicate with the UART device, and the USB serial (serial object) for printing debugging and profiling data.

The software and protocol decoding/translation/bridging have been well debugged and tested previously and is working properly on Arduino with Ethernet2 shield, with the exception of using Ethernet2 instead of Ethernet library and using serial2 instead of serial1, that's all!

Now as I need more processing power I've switched to Teensy 3.6 running at 168MHz

Finally, the problem is as follows: Things are find with only one device (ethernet side or uart side) is sending alone, but the moment that both end devices start sending simultaneously, teensy resets on its own

I tried powering Wiz820 using an external power supply to eliminate the case of power shortage, but nothing changed, I noted it is drawing around 176 mA.

The code is rather big to describe the issue, so I'll start with this description then post some cleaned up and focused section when needed. However, the relevant part of setup() is simply:

// for printf debugging
Serial.begin(250000);
// for communication
Serial1.begin(1500000);
  
// start the Ethernet and UDP:
Ethernet.begin(mac, ip);
Udp.begin(listen_port);

Some additional notes that might help (or confuse) the reader are:
1- Teensy hangs and doesn't function when started while the UART data is already being received.
2- When teensy resets itself due to the problem described above, it won't receive the serial or udp data until all communicating devices are stopped and teensy is reset manually again
3- I have some profiling code in my program, the average cummulative time spent to read uart data (at my application startup) is about 6-8 msec every second. Sometimes this number goes up to 928 msec/sec with the same data being transmitted and never goes normal until teensy is restarted again.

Am I doing something obviously wrong, such as using the Wiz820 w/o adapter or mixing libraries that won't work together? or am I missing something to be done over the Arduino working code?

Cheers

MTA

 

[tonton81]

where is the spi initializer code? are you using spi transactions? did you pull the CS lines high before calling SPI.begin? we need to see more code and wiring schematics.

*** throws a dart at the board

heh, Kurt, I win

 

[KurtE]

*** throws a dart at the board

heh, Kurt, I win

Yep

Hard to say. For example do you know for sure it is resetting and not hanging?

Usually when I hear or see that the program is not working when data is coming. It often is the software is not robust enough to handle conditions, like maybe the data is a set of packets and the code does not properly detect that it started up in a middle of a packet. Examples of this includes, supose the code expects to read two byte count variable of the size of the packet and it gets misaligned and receives two bytes like 0xff 0xff. And then code blindly expects to read in 65535 bytes into an array that is defined as 100 bytes long... Been there - the code then overwrites a bunch of stuff including maybe stack pointers and faults...

Also maybe you run into issues like maybe your code is trying to read into an int variable and on the Arduino it was 2 bytes long, but on Teensy it is 4 bytes. and the code does something like myInt = byte1<<8 | byte2;
And it expects it to be a signed number

But again throwing darts!

 

[MTA]

where is the spi initializer code? are you using spi transactions? did you pull the CS lines high before calling SPI.begin?

Thanks mate for the reply. In answer, there is no SPI initialise code, I'm not using SPI transactions directly, and I didn't pull the CS line high before calling SPI.begin as I didn't call SPI.begin

I assumed that the SPI initialisation is carried out in the Ethernet library, because I have checked the library examples and none initialise SPI directly. This includes Teensy's Ethernet library UDP examples at:

https://github.com/PaulStoffregen/Ethernet/tree/master/examples

If some SPI initialisation is to be done manually, would you please point out the step that are missing?

we need to see more code and wiring schematics.

I need to trim down the code to the minimum set that produces the error before I can post something useful, I'm just eliminating the chances of a silly mistake before doing that

As for the wiring schematic, I followed the adapter schematic:
Teensy3 WIZ820io
------- -------------
9 RESET
10:CS SS
11OUT MOSI
12IN MISO
13:SCK SCLK
3.3v VIN33
GND GND

Cheers

 

[MTA]

For example do you know for sure it is resetting and not hanging?

Yes I believe it is resetting, the ding ding of microsoft windows of devices being unplugged and plugged is hard to miss, plus the arduino serial monitor goes offline then online.

Usually when I hear or see that the program is not working when data is coming. It often is the software is not robust enough to handle conditions, like maybe the data is a set of packets and the code does not properly detect that it started up in a middle of a packet. Examples of this includes, supose the code expects to read two byte count variable of the size of the packet and it gets misaligned and receives two bytes like 0xff 0xff. And then code blindly expects to read in 65535 bytes into an array that is defined as 100 bytes long... Been there - the code then overwrites a bunch of stuff including maybe stack pointers and faults...

The logic of the program and the handling of those nasty cases should all be taken care of, as I pointed out the code has been working properly on Arduino for some time now. I served my time when I was debugging that code

Also maybe you run into issues like maybe your code is trying to read into an int variable and on the Arduino it was 2 bytes long, but on Teensy it is 4 bytes. and the code does something like myInt = byte1<<8 | byte2;
And it expects it to be a signed number

Good one! However I was running my code on Arduino Due which is a 32-bit processor, just like our Teensy

But again throwing darts!

Cheers for that!

 

[tonton81]

i see the ethernet.cpp file uses SPI transactions, however, I dont see it run SPI.begin, such as, when it is not run, the SPI bus will not function, thus neither the library.
Since your using default SPI0 pins per the card of your teensy model, you will still be required to:

pinMode(10,OUTPUT);
digitalWrite(10, HIGH);
pinMode(9,OUTPUT);
digitalWrite(9, HIGH); // or LOW? pick one :)
SPI.begin();

 

[KurtE]

Hi tonton81 - I have not done much with Ethernet stuff, but a quick look at code, it shows some place for example
Ethernet\w5100.cpp that calls SPI.begin().

I will defer looking for now until additional information. Could be a whole variety of things. For example it has been a long time since I looked at Arduino Due. So I don't remember if the byte orders are the same. Also if reading/writing structures, is the PACK the same? Maybe different race conditions which faster CPU is running into. Could be several global objects whose constructor does something, which either depends on others already been called or hardware already configured to work. Example I had constructor who called something which called Serial.print(...) before the Serial object was created...

SO many possibilities...

 

[PaulStoffregen]

Am I doing something obviously wrong, such as using the Wiz820 w/o adapter or mixing libraries that won't work together? or am I missing something to be done over the Arduino working code?

Very hard to say without seeing the code. Even with the code, might be hard to know... but pretty much impossible without.

 

[macaba]

MTA - a quick check... try running this before Ethernet.begin(...)

pinMode(9, OUTPUT);
digitalWrite(9, LOW); // reset the WIZ820io
delay(1000);
digitalWrite(9, HIGH); // release the WIZ820io

 

[MTA]

I agree with KurtE and Paul .. it is a complex problem (in the sense of being composed of too many elements) and hence there are too many possibilities .. The way to go is to break it into smaller problems and solve them no matter how silly they sound

I started from the notice mentioned above that profiling data for reading from Serial port varies considerably in a random fashion across multiple reboots. With some attention I noticed that the serial reads cost too much time when the ethernet library fails to initialise, something I've just noticed it happens, which points fingers towards setup() and libraries initialisation.

Thanks to Macaba I've tried the initialisation procedure advised by him and I've got a consistent proper initialisation of Ethernet over the course of 30ish reboots accompanied with normal Serial read cost! I'll give that some more tests and report back

In the mean time, any advice about the best sequence for initialisation would be greatly appreciated, as symptoms points there.

It would be also great to have a confirmation that the wiring of the wiz820 ethernet module as mentioned above (along with pulling up pins 9 and 10 and grounding the PWDN) is sufficient and correct

Cheers,

 

[PaulStoffregen]

In the mean time, any advice about the best sequence for initialisation would be greatly appreciated, as symptoms points there.

The 7 lines at the end of the WIZ820 adaptor page are the best recommendation to use with the latest software version.

Those lines should be the very first lines in setup(). Serial1.begin() can be done before or after Ethernet.begin(), but is probably best to do before so your serial signals aren't "floating" while other activity occurs. That is, do Serial1.begin() after those 7 lines, but before Ethernet.begin().

If not using a SD card, the 2 lines for pin 4 (SD card CS) are not needed.

It would be also great to have a confirmation that the wiring of the wiz820 ethernet module as mentioned above (along with pulling up pins 9 and 10 and grounding the PWDN) is sufficient and correct

Yes, confirmed, those are correct.

The pullup resistors and CAT811 of the adaptor board are not required if using the 7 recommended lines at the beginning of setup().

The W5200 chip uses a lot of power, at least 200 mA, perhaps more depending on the ethernet magnetics. Beware the misleading current consumption specs, which are sadly common to nearly all ethernet chips. They only specify the current used by the semiconductors. Considerable current also flows through the magnetic parts and gets shunted to ground through the chip. Usually that extra current isn't included in the chip's datasheet.

 

[MTA]

I confirm that the suggested solution by Macaba and Paul got rid of the crashes and restarts altogether.

Thanks everyone!