Random resets

[Lykos1986]

Hi! I was building a gsm/gprs module board together with a PIC 24F32KA304. I am using both UART channels of the PIC in order to communicate with the module and an FTDI chip.

I am monitoring the data between the PIC and the module with a USB Logic analyzer and I am reading the data between the PIC and the FTDI chip into a terminal window (teraterm).

The problem is that sometimes I am reading some strange symbols into the terminal window and the PIC resets itself multiple times sometimes.
For example at normal operation suddenly I will get something like 20 or more dots ( . ) and then I will get the print “Hello” at the terminal (that the first line of my code that’s why I am saying that the PIC resets itself). Sometimes after that I will have normal operation or the PIC will frizz at this position.
Some other times I will get something like 10 equal symbols ( = ) but with an extra line in the middle then stop for a few seconds and then again a few more prints of the same symbols and again frizz at this position.

Firstly I was thinking that those are because of bad power supply. I’ve check the module power and the PIC power and nothing happened that I must pay so much attention. Of course I have small voltage drops during GPRS connects but those are inside the specification limits. Those voltage drops are mirrored to the PIC creating something like a 10 – 30mV prop in phase with the voltage drops of the module. The power of the PIC is 2.8V and those drops should not create any operational problem.

Then I’ve checked the serial data between the module and the PIC. I assumed that maybe I am getting some non-standard data and somehow the PIC (combined with my code) gets crazy because of those! But the serial line is perfectly clean!

So, do you thing that this maybe happening because of non-good code? Something at my interrupt service routine (that reads the data received from the module) is wrong? Maybe because it is a little bit big (I’ve read somewhere that the ISR must be as small as possible)

Any help, suggestions or info of what I have to look?

[Ttelmah]

Seriously, you don't say how you are detecting the 'small drops'. Odds are that if this is something like a scope (or worse), a meter, it'll be missing the 'real' instantaneous drops. If you can measure several mV of drop, then you have inadequate regulation/smoothing.

[FvM]

Hardware resets can be caused by GSM supply current pulses or RF being picked up by the digital circuit.

Software resets are often caused by PIC24 error traps.

The reset cause can be determined by inspecting the RCON register.

[Lykos1986]

[temtronic]

Could easily be a 'power supply ' problem,poor PCB layout/design,lack of decoupling caps,bad solder joints on unused pin pullups,bad ground bus.
Without seeing a picture of the board,hard to tell.
Assuming a 'wallwart' type power supply,could be noisy if a switching type,lack of reserve power,etc.
What are the current demands of the project? You should have 3x that as a minimal power supply.
To isolate...I'd run the project off a car battery,see what happens.If it fails..probably not a supply problem.
Other sources of 'random resets' can include using WDT,internal osc,ISR enabled but not impletmented,accessing RAM wrong( pointers,etc.).

Key is to reduce program to minimal that does fail and diagnose what's left.Start with JUST the PIC,simple 'hello world' code,run for a day,does it fail? If not, add more code a section at a time,testing long enough to prove sucess or failure.

hth
jay

[gpsmikey]

One thing that can drive you nuts if you have multiple things all hooked together, each with a different supply or ground. Ground faults/loops can cause all sorts of odd things to happen. Make sure that ground is tied together on all the stuff you have hooked together.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[PCM programmer]

What about the stack size issue ?
http://www.ccsinfo.com/forum/viewtopic.php?t=49585


Search the CCS forum archives. Do a search for this:

[Ttelmah]

Other simple one that hasn't been mentioned. Floating inputs.

Any pin that is not set as an output, if not being driven, could easily pick up nasty spikes from the RF. If you have any unused pins, set them as outputs.

Also what is connected to MCLR?.
MCLR alone of standard PIC pins, does not have any diode protection (because it also feeds Vpp). If MCLR is disabled, it'll still result in a reset, if the voltage on this pin goes fractionally above Vdd....
If you have a 'standard' resistive/capacitive network on MCLR, without a diode across the resistor, then if the supply droops, the MCLR pin will go above Vdd.

Stack however is the first one to look at.

Best Wishes

[jeremiah]

I have noticed on that chip that it will not operate correctly at the high end of its frequency range. What speed are you running it at?

For example, I tried running it at 22.1184 MHz and experienced the exact same thing you are (even on couple line main programs). When I dropped down to 11MHz everything worked fine. Even though the data sheet says it can handle 25MHz, try running it slower and see if the issues remain or go away.

EDIT: also, if you do drop the frequency pay attention to what the data sheet says about which fuse goes with which speed. If I remember correctly, the standard ranges for most PIC24s don't apply to this chip (like the XT vs HS ranges I think).

[Ttelmah]

As a further comment, have you looked at the UART transmit errata on this chip. Uurgh!...
Really implies you must use interrupt driven transmission, and only load characters one at a time on the interrupt. Horrid fault.

This could result in the garbage data, and then if your error handling has a fault, or uses extra stack space, this could give the reset....

Best Wishes

[jeremiah]

That worried me too. I've been testing it for over a year just using normal non isr transmit without any issues. I'm not sure if I am reading the errata right or not, but I would have expected issues. I haven't seen any. I'm running at both 9600 and 115200 on separate uarts.

EDIT: Maybe that's why running it at the higher crystal frequency resulted in resets with simple printf calls but slower crystal frequencies didn't? I know that is a shot in the dark...but something to consider.

[Ttelmah]

That is a very interesting possibility.
If the problem was found on a normal board operating at perhaps 80% plus of it's maximum frequency, I doubt if anyone would have tried running slower to see if the fault disappeared.
It'd need somebody to do a really basic data transmission test at full clock speed, and at perhaps half speed and see if there is any change. If there was, it might explain a lot....

Best Wishes

[Lykos1986]

[Lykos1986]