Written by ARGE.
Hi,
We want to use WIZ812MJ module on our products. We designed a prototype with UC3A512 32 bit AVR microcontroller and WIZ812. We use parallel interface. It seems like working. But the module returns wrong datas sometimes.
For example, after the initialising of the module we write 0XFF to 0X4000 address(0.socket’s transmit buffer’s first address.). We wrote a simple software first writes 0XFF to 0X4000 and then continously reads 0X4000 address to check the interface. Approximately %35 of the readings are not correct(not 0XFF). We checked all the timings on the ossilloscope and everything is correct. Also we tried many combinations of the timing but nothing changed.
Do you have any suggestions? If we do same thing for different addresses we get different results. Some addresses are better, some are not. And also if write different numbers instead of 0XFF we get different results. It seems like, decreased 1’s in the number gives better results. We mean, for example we can write and read small numbers like 0, 1,2, 50, etc perfectly. 255, 127, 63 have much more problems.
Also there is “heat” on the chip. We don’t know what is the temperature. But it is around 50-60C. Is it normal? We measured the power supply current and it is around 150mA.
Please help urgently. Thanks in advance.
Hello ARGE.
Thank you for your interest to WIZnet and ourproducts.
If you use parallel interface to connect the 32bit MCU and the WIZ812MJ, the data communication is executed by 8bit data line.
If so, please check the 32bit MCU support the 8bit mode.
If the MCU not supports 8bit mode, you should mapping the 8bit line to 32bit line Use only 8bit among 32bit and other 24bit should be reserved.
Also the address line should be mapped according to the interface (indirect, direct mode).
Sometimes a internal variable process occurs ‘Casting error’. So please also check it.
The normal operation temperature is 0~70C. So your module is fine.
Thanks.
Thanks for the answer.
Yes, our microcontroller supports 8bit mode and it works. We see on the ossilloscope the address lines, CS, RD and WR lines are OK on the reading. But the problem is ( we see it on the ossilloscope) the read data is not stable. The address is same(0X4000) but the responce is not stable. We can write and read all the common and socket registers. But we can not read the memory. Is this normal? Reading of registers normally and not reading of the memory is strange.
We guess that we can read the buffer anytime without any restrictions, right? And we must read same byte from same address(nothing writes on it), but we can’t. It seems like the chip is not answering properly because of a reason.
We feed the module with a 3.3V switching power supply from USB 5V. We measure 3.2V on the power pins. We think this is OK, right?
The distance between the module and the microcontroller is around 12cm. May this cause the problem? But even we use very slow reading speeds, the problem is same.
Best regards
Hello ARGE.
The address 0x4000 is relative address. So the first address of TX buffer is 0x4000 + base address of your address system. In the last answer, we assume the base address is 0x0000 but actually it is depended on your address system. Please check your address system.
To analyze your READ timing, please attach your READ timing captured by oscilloscope. Then we analyze the timing and will give you some valuable help.
Thanks.
I am also having the same problem as someone posted a few weeks ago. I get corrupted memory reads and lost bytes, especially after reading bytes of value “FF”.
A test program connects to the WIZ812 and sends 256 bytes repeatedly, the bytes are even values from 00 through FF, interlaced with FF values (00,FF,02,FF,04,FF,etc). The output below shows what is received, you can see lots of bytes are just “LOST”.
I am using same code I have with NM7010 module with a few changes for WIZ812MJ (rev 1.0) module. Also note I keep CS always LOW, and only toggle RD/WR, using INDIRECT, parallel mode…
I have been trying to debug this for over a week, put scope on RD/WR lines and power line, don’t see any problems, RD/WR pulses are long enough, no glitching.
wiznet connection EST
00 ff 02 ff 04 ff 06 ff 08 ff 0a ff 0c ff 0e ff 10 ff 12 ff 14 ff 16 ff 18 ff 1a ff 1c ff ff 20 ff ff 24 ff 26 ff 28 ff 2a ff 2c ff 2e ff ff 32 ff 34 ff 36 ff ff 3a ff ff 3e ff ff 42 ff 44 ff .
46 ff 48 ff ff 4c ff ff 50 ff 52 ff 54 ff ff 58 ff ff 5c ff 5e ff 60 ff 62 ff ff 66 ff ff 6a ff 6c ff 6e ff 70 ff 72 ff ff 76 ff 78 ff 7a ff 7c ff 7e ff 80 ff 82 ff 84 ff 86 ff 88 ff 8a ff 8c .
ff 8e ff 90 ff 92 ff ff 96 ff ff 9a ff ff 9e ff a0 ff a2 ff a4 ff a6 ff a8 ff ff ac ff ff b0 ff b2 ff b4 ff ff b8 ff ff bc ff ff c0 ff c2 ff c4 ff ff c8 ff ff cc ff ce ff d0 ff d2 ff ff d6 ff .
d8 ff da ff dc ff de ff e0 ff e2 ff e4 ff e6 ff e8 ff ea ff ec ff ff f0 ff ff f4 ff f6 ff f8 ff ff fc ff ff 00 ff 02 ff 04 ff 06 ff 08 ff 0a ff 0c ff 0e ff 10 ff ff 14 ff 16 ff 18 ff 1a ff 1c .
Hello Mark.
Thank you for your interest to WIZnet and our products.
It may has some errors on your test code.
Check your data type (isn’t it int type? char type?).
And if your MCU is not 8bit processor, you should change it to 8bit mode. Unfortunately it has not 8bit mode, you should porting your test code.
Note that, process your data for 8bit unit.
If continuing your problem, please send your code to analyze.
Thanks.
Hi-
OK let me explain the problem better as I have done more testing and you are not understanding it. I have some code to receive bytes and display them one at a time, the code looks like this:
set auto-increment mode
when incoming data is received, compute buffer address, etc
set buffer starting read address in wiznet
loop (until read all bytes)
{ read byte; display byte}
Now I have a test program sending bytes to the Wiznet from a PC, if I send 00 01 02 03, I receive them fine. But when I send bytes such as 00 ff 01 ff 02 ff 03 ff, I often lose a byte after receiving an FF, (for example maybe I get back 00 ff 01 ff ff 03 ff, losing the 02.
This is not due to any 8/16 bit code issue.
I had a guess that your module is having a problem with the auto-increment function, so I wrote some new test code to not use that, and instead set the address before each read, for example:
when incoming data is received, compute buffer address, etc
addr = buffer starting read address in wiznet
loop (until read all bytes)
{ set read addr in wiznet; read byte; display byte; addr++}
Now, this new code works properly (except for some reason the first byte of a connection is wrong). But as the problem is mostly gone, I suspect that there is a problem with your module, that when it receives FF (or other values with lots of 1s), that the auto-increment function happens twice. Maybe due to some hardware glitching or bad caps on your module. I don’t have any other ideas at this time but it sure seems like the issue is related to hardware or your module, and not my code.
Hello Mark.
Thank you for your interest to WIZnet and our products.
The Data Read/Write Timing may has some problems.
Since the ‘Auto-increment’ function is executed by internal Hardware logic of W5100 and it has been used by our customers for couple of years, there is no problem with ‘Auto-increment’ function.
As your test, if disable the Auto-increment function and realize it by F/W, then its timing can be changed.
So it may have good timing.
Please send your test code to analyze the problem.
Thanks again for your valuable comment.
Hi-
Can you tell me how the customer resolved the problem described in messages 2831 and 2833? Since my problem is similar maybe the answer to that will help me find my problem.
thanks.
The problem with the Wiznet chip auto-incrementing an extra time once in a while turned out to be a little glitch in the RD signal. Maybe due to a very strong output from the PIC, or the 4 inch long trace, but when the RD signal went low it would undershoot by almost a volt for a few nanoseconds, and this caused the Wiznet to auto-increment an extra time. I fixed this by adding a terminating resistor in series with the Wiznet and PIC on the RD line (and will probably add one to the WR line also).
Hello Mark.
Glad to hear that your problem has been solved. Please feel free to asking your problem.
Thanks.
