Mystery lockups on 18LF6722

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

Hi,
Has anybody had unexplained lockups on this (or other pics ?).

It's running from 3.3 v at 16 mhz (internal osc 8mhz with PLL).
MCLR has been tried disabled or pulled to 3.3v with 10k and a 0.1uf to ground.
The watchdog timer is set for 2 seconds and there is only one restart_wdt at the end of the main loop. No WDT resets in delays or I2C code.
I don't use sleep or idle or anything like that, it's always on.

The code is complied with PCW V3.249

Timer0 and timer 4 are running on interrupts, timer 2 is running but only for PWM (no ints), the ADC is off. I'm doing software I2C (CCS code), software SPI (my code) and hardware RS232 (my code) as well as talking to a graphic LCD display.

At random intervals of between 1 and 60 mins (approx) the cpu will lock solid, the interrupts stop running and there is no external activity.

The lockups only seem to occur if 4 tri colour leds are all on (this initally looked to be a big clue), these are multiplexed with the green anodes and red anodes for the leds commoned to 2 port pins (a.4 & a.5) and the common cathodes to another 4 port pins (f.0 to f.3) via 150R resistors.
But testing with 1k resistors eliminated anything to do with current drain from the common ports as it still locked up.
Also tried setting the ports tri state rather than a level for off leds as there did seem to be some spikes occuring on the port pins from stored charge (or something like that) in the leds.
The leds are multiplexed from the timer4 interrupt.

Fuses are:
#fuses WDT, WDT512, INTRC_IO, PROTECT, BROWNOUT, PUT, STVREN, NODEBUG, MCLR, NOIESO ,NOFCMEN
#fuses NOLVP, NOWRT, NOWRTD, NOWRTB, WRTC, NOCPD, NOCPB, NOEBTR, NOEBTRB, BORV25, NOXINST, NOLPT1OSC

Any thoughts ?

Initially i thought the problem was fixed but it's come back now we have shipped units to the customer (don't they always).

I can't really upload the code as theres 20,000 lines of it excluding the fonts, it's 64k compiled. But i can upload snippets.

My biggest question is what can cause the cpu to lock that woudn't be caught by the watchdog timer.

Many thanks,

Jim Hearne

newguy · Joined: 24 Jun 2004 Posts: 1903

Big clue (for me) was the mention of a graphical LCD. Do you use ANY ccs supplied source code to interface to the LCD?

I have one device that I used the ccs graphical LCD routines for drawing objects, and it occasionally locks up too. This isn't a production product - just something personal, so the lock ups are annoying but not crucial. I also developed a commercial product and had to write my own LCD interface routines/drawing routines. No lock ups with my code at all.

Also do a search in all your code/files for 'while' - there may be a hidden while loop somewhere in one of your drivers where the processor may be waiting for a certain line to go to a certain state or whatever.

Hope this helps.

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

Hi Newguy, thanks for the reply.
The display code is a heavily modified version of some code i found on the net. But it's been running for a long time and i trust it.

If the code was getting stuck in a while (or any other loop) the watchdog timer should catch it and restart the PIC.

I've just compiled the code with 4.020 and it's just run overnight so it may be that theres a bug in V3.249 thats been fixed in 4.020

More testing is required.

Jim

adrian · Joined: 08 Sep 2003 Posts: 92 Location: Glasgow, UK

How about BROWNOUT?

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

Brownout is enabled and set to 2.5volts.

Jim

adrian · Joined: 08 Sep 2003 Posts: 92 Location: Glasgow, UK

So if you were concerned about this..

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

I have the restart cause available on a diags screen but as the PIC locks up rather than restarting (which a Brownout would do) i've no way of seeing the restart cause, assuming it was actually set to anything when it locked up.
The pic needs a power cycle or reset to unlock it, both of which overwrite the restart cause.

Thanks for your thoughts,

Jim

rnielsen · Joined: 23 Sep 2003 Posts: 852 Location: Utah

It's kindof hard knowing what to guess without seeing any code but then I'm not good at going through other people's code.

Do you, happen, to have an interrupt enabled without an ISR function to service it. Even if you don't use it, it can cause hard lock-ups. I've experienced this in the past when I had one of the timer interrupts enabled but no ISR defined for it. I wasn't using the timer, or it's interrupt, and when I did a delay() the PIC locked up hard even though I had the WDT enabled and running.

Just a thought. Good luck and don't lose too much hair, pulling it out.

Ronald

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

Hi Ronald, thanks for the reply.
I've just double checked and all interrupts that are enabled (in my code) have ISR's.

Rather than have somebody look through the code to see whats wrong i'm looking for suggestions as to what can cause a hard lockup that doesn't get picked up by the watch_dog.

At the moment compiling with 4.020 instead of 3.249 seems to fix the problem but i'd like to know why.
I've just renewed our subsription so i can try the latest version as it seems 4.020 does have some other known bugs.

I hope they've improved the IDE as well, i really don't like the series 4.xxx one.

Thanks,

Jim

newguy · Joined: 24 Jun 2004 Posts: 1903

The only time I've ever experienced 'mystery' lockups was when I used CCS code, unchanged, in projects.

One big recent example concerned the CCS CAN code for PICs equipped with a CAN transceiver. The CCS code doesn't address CAN errors at all and will instead simply wait for a clear transmit 'slot' in a while() loop. The only problem is that if all slots are clogged with queued outgoing messages, the code hangs. Outwardly, it appears as if the PIC completely hangs, even though the watchdog is enabled and working properly. Once I realized that a watchdog reset doesn't clear the logjam of queued outgoing messages in the CAN transceiver I was able to fix the problem properly.

I was leery about using CCS drivers before this issue came up, but I am dead set against using any of it without completely picking it apart now, line by line, to try and identify possible issues.

Jerry I · Posted: Wed Mar 21, 2007 2:01 pm

Quote:
It's running from 3.3 v at 16 mhz (internal osc 8mhz with PLL).

Just a comment You say its running at 16Mhz.

If you are using the internal OSC at 8Mhz with PLL x 4 Should = 32MHZ.

#USE CLOCK 16MHZ or 32MHZ.

Maybe your I2c timing may be off ???.

I have been using the same chip with external OSC of 10MHZ with PLL = 40MHZ with no problems.

Good Luck

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Jim Hearne · Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK

Thats my last step to try and track it down, except i'm using the comms port as part of the device so can't use it for comms.
I've got the lcd display but it's only updated at the end of the main loop so my plan was the values to a location in eeprom and then at power up read that into another variable and display it so i can see where it locked up last time.

I'm not sure if my boss will give me time to do it though, he said it's just a compiler problem and to use the later version.
Except i'm having more grief with 4.030 as you've seen.

Thanks,

Jim

rnielsen · Joined: 23 Sep 2003 Posts: 852 Location: Utah

If you have extra I/O available, you could connect LED's to them and turn one on at the beginning of each routine and then back off just before it exits. When the processor locks up just look which LED is still lit and that's the routine you need to concentrate on. Do it multiple times to ensure that it's the same routine causing your lock-ups.

Make sure that you have the correct bypass caps at the VCC & GND pins. Quick spikes can really hose a PIC.

Ronald