RAM Corruption using ENC28J60 drivers

[eric]

I'm a bit baffled by this problem, having used PIC controllers for several years.

Running the PIC18F2525 with ENC28J60. UDP only IP's all hardwired for now. Adjusted the example code so that I can call UDPTX and UDPRX, but not often. And without interupts. No timer0 etc.

After a while, hours of proper operation, many of my RAM varaibles become over written. So many of my set points have changed. yet the code is still, by and large, TX and Rx ing data

I have no clue how to solve this. only traces of deterministic behavior

Any suggestion welcome.

[eric]

OK - so this was more of a rant than a post... Came home at 1:00AM to find the project failed (again). Sigh...

Compiler 3.249
18F2525
ROM used: 31182 bytes (65%)
Largest free fragment is 15568
RAM used: 590 (15%) at main() level
699 (18%) worst case
Stack: 16 locations

I have two sections of code.

The original program, I've run for a year, but with serial port based packets

I have since got the ENC28J60 connected to SCLK/SI/SO to handle the packets. I've using the UDP example code from the CCS ethernet devboard 18F4520? as a "driver". This code, setning dummy packets, on its own had no issues. Do not need DHCP, ARP etc so all this is disabled. Only exchage a very low rate of packets, less than one per sec.

The problem is, after some hours, the some of variables in RAM for the original code get over written. Event though I do not access or change them. That said, they are variables that have routines to change them.
Its a bit deterministic, in that sometimes the values changed are consistent 210 to -> 84. But not always.

I read somewhere that if an interupt is generated during a write of a Long that the second byte can end up elsewhere.

I have managed to get all the interupts OFF and still get satisfactory operation. (I found I had not done so as of last evenings attempt).

So far its been running for 4 Hrs. But I have no reason to be optimistic that this is fixed.

If it at least would show the fault sooner it would be easier to fix.

-------------------------------------------------------
I note that the ICE2000 is reasonable affordable. I should be able to trap a change in ram location with this, and trace the offending bit and or interupt (if enabled)?



Eric

[asmallri]

If this is your own hardware and using Rev 1 to 4 ENC28J60, check that you are driving the SPI clock between 8MHz and 10MHz. Also check you have plenty of decoupling capacitors around the ENC and the PIC and that your power supply is capable of supply 250mA at 3.3 volts.

Check the rev of the driver. Rev 4 and below have a problem with DMA corrupting the RAM. Basically the DMA option is useless to you on these rev chpips. There are also other work arounds which all deal with pointer corruption on rev1 to rev4 ENC28J60s.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!