PIC18 - reset in middle of running code - Page 1
Forum section: electronics / general

author: richcj10
author_rank: Unknown
timestamp: December 27, 2012, 07:03:58 pm
content: Hi,I have had Atmega's lock up on me but never reset while executing code. Any ideas?P.S.- WDT disabled, running board off of Power supply.Thanks,Rick

author: AndyC_772
author_rank: Super Contributor
timestamp: December 27, 2012, 07:24:57 pm
content: A few obvious things to check:- do you have a pull-up resistor between MCLR and VCC?- do you have decoupling caps on the power & ground pins, physically located right next to the pins and on very short leads?- what's the brown-out voltage set to (#pragma config BORV)? Is it anywhere close to your VCC voltage?- where's the clock coming from, is it an external clock or the internal RC oscillator / HSPLL?What's the code doing? Is it possible it's just a software bug writing over a pointer or something and causing a crash?

author: AlphZeta
author_rank: Regular Contributor
timestamp: December 27, 2012, 07:43:22 pm
content: Also, if the power supply is shared with some inductive components (e.g. motors), this tend to happen quite a bit if the decoupling and filtering of the power supply is not sufficient.

author: richcj10
author_rank: Unknown
timestamp: December 27, 2012, 09:48:43 pm
content: It is not a power issue. I have checked it with a scope. No inductive loads attached to the device.It works for hours and then reboots into a loop that continues to reboot. I haven't looked at the Brown out but it doesn't seam likely that it would be causing this.

author: Psi
author_rank: Super Contributor
timestamp: December 27, 2012, 10:08:06 pm
content: Have you tried another chip?That will prove if its a software issue or a faulty ICAre you doing anything complex with pointers?Are you using a bootloader?Using the EEPROM values for anything? especially eeprom address 0 ?

author: MikeK
author_rank: Super Contributor
timestamp: December 27, 2012, 11:03:19 pm
content: I don't know about AVR, but PICs have the ability to determine the source of the reset. If AVR does you could add this to your program.

author: joelby
author_rank: Frequent Contributor
timestamp: December 27, 2012, 11:52:28 pm
content: Yes, you could try logging the value of RCON at power. It might help you determine what caused the reset.I thought there might also be an illegal instruction/divide by zero trap or interrupt but I can't actually see any evidence of such a thing on a PIC18 with a casual glance.

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 12:05:06 am
content: This is a PIC, How would you track a reset?Thanks,Rick

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 12:06:07 am
content: It has a External EEPROM but it is not using it when reset normally occurs...

author: UPI
author_rank: Regular Contributor
timestamp: December 28, 2012, 01:00:23 am
content: Have you tried a much simpler program to see if it still locks up? If it does not, you could then add the more complex portions until it starts locking up again.Divide and conquer.

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 01:03:51 am
content: Here is the code I am running:Code:program MyProjectdim cnt, prevcount, prevcount1 as word ' Define variable cntsub procedure interrupt ' Define interrupt subprocedurecnt = cnt+1 ' Interrupt causes cnt to be incremented by 1PIR1.TMR1IF = 0 ' Reset bit TMR1IFTMR1H = 0x80 ' TMR1H and TMR1L timer registers are returnedTMR1L = 0x00 ' their initial valuesend sub ' End of interrupt routinemain: ' Start of programTRISA.3 = 1 'Serial I/OTRISA.5 = 0 'Serial I/OSoft_UART_Init(PORTA, 5, 3, 2400, 0)TRISC.0 = 0PORTC.0 = 1 ' Initial value of PORTB bitsTRISC.7 = 0 ' PORTB pins are configured as outputsT1CON = 1 ' Set timer TMR1PIR1.TMR1IF = 0 ' Reset bit TMR1IFTMR1H = 0x80 ' Set initial value for timer TMR1TMR1L = 0x00PIE1.TMR1IE = 1 ' Enable interrupt on overflowINTCON = 0xC0 ' Enable interrupt (bits GIE and PEIE)Soft_UART_Write("D")Soft_UART_Write("O")Soft_UART_Write("N")Soft_UART_Write("E")Soft_UART_Write(10)Soft_UART_Write(13)while 1 ' Endless loopif ((cnt - prevcount) > 1400 ) then ' Rtn 1 - chg checkprevcount = cnt'PORTC.0 = NOT PORTC.0Soft_UART_Write("C")Soft_UART_Write(10)Soft_UART_Write(13)end ifif ((cnt - prevcount1) > 4200 ) then ' Rtn 1 - chg checkprevcount1 = cnt'PORTC.0 = NOT PORTC.0Soft_UART_Write("D")Soft_UART_Write(10)Soft_UART_Write(13)end ifwendend. ' End of program

author: Psi
author_rank: Super Contributor
timestamp: December 28, 2012, 01:14:06 am
content: Quote from: richcj10 on December 28, 2012, 01:03:51 amI had someone tell me off for using a variable named "cnt". Apparently it's offensive.I laughed pretty hard, which wasn't the best plan since they were serious.

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 01:21:37 am
content: lol

author: mazurov
author_rank: Frequent Contributor
timestamp: December 28, 2012, 02:12:13 am
content: You may want to explicitly define a handler for each interrupt in this device with while(1) inside. IIRC default interrupt handlers all jump to zero.

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 03:41:34 am
content: Quote from: mazurov on December 28, 2012, 02:12:13 amI hope I don't sound too stupid but what do you mean by this?

author: Psi
author_rank: Super Contributor
timestamp: December 28, 2012, 04:08:57 am
content: I don't know PICs, but i think he means if your code is triggering an interrupt which has no handler it will reboot the micro

author: mazurov
author_rank: Frequent Contributor
timestamp: December 28, 2012, 05:16:33 am
content: I looked at PIC18 datasheet - there are only two interrupt vectors, one for high and another for low priority. Do this: write an ISR for each one and place a breakpoint inside each ISR. This way you can see if ISR gets called accidentally. You need to work around the timer code which is already in the ISR.

author: Skimask
author_rank: Super Contributor
timestamp: December 28, 2012, 05:26:32 am
content: There's a register in the PIC that you can look at AFTER the reset to figure out what caused the reset itself.But, since we don't know which PIC, and don't know if that is actually the full code, kinda hard to say.A bit more, ok, a lot more information, might be quite a bit more helpful, like maybe a schematic, config bits, the list goes on.I've been using PIC18's of all types for quite awhile and don't remember any cases of "random resets" that I haven't been able to eventually explain...usually thru my own mistakes.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 28, 2012, 05:32:07 am
content: Far out man...What pic18 are you usingWhat compiler are you usingWhat incarnation of basic code is thatAre you running this on a dev board or something you madeDo you have schematicsWhere do your variables ever get initialisedIs the interrupt code placed at the proper inturrupt vectorThe cnt variable is a word which means to process it in main it will take several interruptable cycles which makes it quite possible that the hibyte (required for values greater than 255) never gets touchedetc, etc...

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 05:38:20 am
content: It is a PIC18F47J13I cant show the schematic because of a NDA but it is hooked up correctly and functional.The IDE is Mikro Basic ProI have used this IDE in the past with no problems on this board.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 28, 2012, 05:42:59 am
content: May i suggest that for the time being, do away with the interrupt and just pole the interrupt flaginstead ofwhile 1blahblahwhile NOT PIR1.TMR1IFblahblahand previous to that just comment out any code that enables interruptsThe interrupt flag will be set regardles, when the timer overflows, all you have to do in the while loop is reset it

author: mamalala
author_rank: Unknown
timestamp: December 28, 2012, 05:46:33 am
content: A few things. You have no setup for the OSCCON registers to select which oscillator/clock source to use. How does the soft-uart know what the actual clock rate is?Speaking of soft-uart, how does it time the bits it sends? Using a timer also? And if so, which one? There is the possibility of a conflict there. Or does it use an interrupt? If so, how does your compiler handle that?Then, you use "cnt" in the interrupt as well as the main code. However, i see no provisions to tell the compiler about it. Using a variable shared between interrupt and other code requires special handling of the variable. Plus, you have it defined as word, which requires multiple accesses to it. Imagine that your variable is 0xFFFF. Now you do the first check. The substract operation will load one byte of the variable, substract one by of the other one, then does the same with the second byte plus the proper status bit for over/underflow carry of the previous operation.Now you have the problem that during this the IRQ can kick in and modify the variable. Which means that the result of the operation will be just wrong.A similar condition can happen when you load the other variables with the contents of "cnt". It will take 4 clock cycles to do that. It can either use two MOVFF operations, each using two clock cycles, or it can use two MOVF/MOVWF combinations, again using two cycles for each combination. Right in the middle of that it could happen that the IRQ changes the cnt variable now.Depending on how the compiler generates the interrupt code there could also be problems with the call- and variable-stack save/restore. The PIC18 chips have two interrupt levels, low and high priority. The high priority can save/restore some of that stuff automatically, while for the low priority it needs to be done by hand. If you now call functions, and a IRQ happens during that, there is a chance of messing up any of these stacks, leading to corrupted data or return stack if the IRQ is done.Greetings,ChrisEdit: Forgot to explain that substraction thing a bit better. As said, lets assume cnt is 0xFFFF. The other variable is 0xF000. You would expect the result to be 0x0FFF. But what happens is that first the low byte is substracted, 0xFF - 0x00 = 0xFF. Now the interrupt occurs, cnt becomes 0x0000 (since it overflows now). So on the high byte part of the substract, you now would have 0x00 - 0xF0 instead of the 0xFF - 0xF0.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 28, 2012, 06:00:00 am
content: Just looked at the data sheet the register to interigate after a reset is RCON

author: Kremmen
author_rank: Super Contributor
timestamp: December 28, 2012, 09:35:58 am
content: The embedded peripherals in a MCU are usually able to generate an interrupt when something interesting happens. Say a USART receives an incoming data byte, it then generates an interrupt to flag the event. The built-in interrupt controlled (another embedded periperal) does what the name says- interrupts the flow of program and causes a jump to the point in program space specified for that interrupt. The details vary by maker and chip type, but the idea is always the same.Often the jump point - if nothing is specified - is address zero by default. And often jumping to zero address causes the program to re-initialize from start. That may be what you are seeing.Remedies:easy: run with all interrupts disabled. There is always a register bit somewhere that controls global interrupt enable/disable. Once disabled, no interrupts will be generated. But then you won't be able to use any of them either.proper: See that interrupt generation from all embedded peripherals is set in the proper way, either on or off accordingly to whether the interrupts are desired and properly specified. For every enabled interrupt, you must provide the interrupt handler. This is a piece of code that is specifically tied to the particular interrupt by using a mechanism provided for this purpose in the programming language. Interrupt handlers must be written in a specific way but otherwise they are just procedures like any other. The compiler/linker creates the correct jump instructions once it has sufficient info to associate your procedure with a particular interrupt type.

author: ptricks
author_rank: Frequent Contributor
timestamp: December 28, 2012, 02:01:38 pm
content: Are you turning off the interrupts after the interrupt is triggered ? If not you can get into a situation where the interrupt is triggered, jumps to the sub routine and is triggered again , not allowing the code to progress further and causing an overflow in the variables.sub procedure interrupt ' Define interrupt subprocedurecnt = cnt+1 ' Interrupt causes cnt to be incremented by 1PIR1.TMR1IF = 0 ' Reset bit TMR1IFIf the interrupt is triggered again you will increase cnt by one over and over until the routine passes the reset without it being triggered again.I suggest changing it toCode:sub procedure interrupt ' Define interrupt subprocedurePIE1.TMR1IE = 0 'Disable timer interruptcnt = cnt+1 ' Interrupt causes cnt to be incremented by 1PIR1.TMR1IF = 0 ' Reset bit TMR1IFTMR1H = 0x80 ' TMR1H and TMR1L timer registers are returnedTMR1L = 0x00 ' their initial valuesPIE1.TMR1IE = 1 'Enable timer interruptend sub ' End of interrupt routine

author: richcj10
author_rank: Unknown
timestamp: December 28, 2012, 06:14:52 pm
content: I ran the code today with it printing the value of RCON today.I got this when it rebooted: 00111100This tells me nothing other than maybe a BOR occurred.Quote from: ptricks on December 28, 2012, 02:01:38 pmI will try this...

author: Jon Chandler
author_rank: Frequent Contributor
timestamp: December 28, 2012, 09:03:12 pm
content: I don't believe you've answered questions about the circuit except to say "it's right."Two things often cause mysterious resets:1. /MCLR not pulled up to Vdd with a 10k resistor.2. Lack of 0.1 µF bypass caps across power pins.Also, be sure ALL power and ground pins are connected.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 29, 2012, 01:13:08 am
content: Quote from: richcj10 on December 28, 2012, 06:14:52 pmThats the exact value to be expected after a Power On Reset (POR). Above each bit in the register description value you have X/X-n where n denotes the value after a POR. _POR and _BOR bits have to be SET immediately after a POR by your software for those bits to be meaningfull. If you read RCON after one of your "reboots" and they are still set then you know its a software issue, which is what I suspect is the isue here.

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 02:47:17 am
content: Quote from: Jon Chandler on December 28, 2012, 09:03:12 pmThe hardware is fine, it actually has more capacitance on the power pins than .1uf.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 29, 2012, 05:33:29 am
content: Quote from: richcj10 on December 29, 2012, 02:47:17 amThere should at least be 1 0.1uf per Vdd pin.Large caps provide bulk charge and are to slow to bolster the voltage for fast transient current demands on the power distribution system (PDS). Smaller caps placed very close to the power supply pins to reduce parasitic inductunce and therfore delays in current supply are a must for any high speed digital device.Having said all that what you said could be that you have more thanjust 10.1uf cap on the supplies

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 05:58:03 am
content: The board has at each Vcc pin on the uC a .1uF and a 10uF cap. Hence the comment that it has more than .1uF.At the AVCC pin I use a L/C circuit to filter out noise there. (just encase you ask)I have been designing hardware for some time now and know a thing or two about uC hardware design. (even in nosy environments like this board will be in)Software on the other hand (as strong as I am with computer c programming) am unfamiliar with PIC's (i am a AVR guy) and there fcn. registers in general.

author: Unknown
author_rank: Unknown
timestamp: December 29, 2012, 06:08:30 am
content: Quote from: AlfBaz on December 29, 2012, 05:33:29 amNote that larger here mainly means physically larger (inductance) or higher K dielectric. A 1 uF X7R cap in 0805 shouldn't be any worse than a 100 nF X7R cap in the same package. A 0.1 uF electrolytic in a through-hole package will perform much worse.Quote from: richcj10 on December 29, 2012, 05:58:03 amBeing less arrogant might get you farther. Having years of experience does not preclude you from making bonehead mistakes. The hardware may very well be OK, but don't exclude problems beforehand. This reminds me of a story I once heard about troubleshooting a steam engine. A bunch of senior engineers made a list of possible causes and a list of things that were definitely not responsible for the problem. A junior engineer was assigned to check each of the possible causes, and eventually found it was caused by something on the 'definitely not' list.

author: JuKu
author_rank: Frequent Contributor
timestamp: December 29, 2012, 06:40:36 am
content: Quote from: Jon Chandler on December 28, 2012, 09:03:12 pmAnd the part keeps resetting...( Believing in something against empirical evidence is ...).Wouldn't be the first uC with a bad solder joint or ESD damage on a critical pin.

author: Skimask
author_rank: Super Contributor
timestamp: December 29, 2012, 06:48:41 am
content: You've got the required caps on the Vcap/Vddcore pins? (Datasheet section 2.4)Is this the 18F27J13 or the 18LF27J13?

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 08:17:17 am
content: it is the 18F27J13 with the VDDCore pin. I have 10uF ceramic cap on it.

author: Skimask
author_rank: Super Contributor
timestamp: December 29, 2012, 08:57:37 am
content: And .1uf's across the Avdd & Avcc pins?

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 09:55:49 am
content: yes

author: Psi
author_rank: Super Contributor
timestamp: December 29, 2012, 10:00:30 am
content: I've not read the whole thread but at this point i'd probably do a binary search elimination analysis. (assuming you've already tried a replacement mcu)Remove half the features in the code and retest for the fault.If the fault is gone, go back to the code you removed and retest half of that.If the fault is still there remove half of the remaining code/features and retest.Rinse/repeat.It's the quickest way to find the line/feature causing the problem (or at least the area involved in the problem).For example you might find when you stop reading the ADC the problem goes away.

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 10:01:34 am
content: Not a bad idea

author: lewis
author_rank: Frequent Contributor
timestamp: December 29, 2012, 01:03:51 pm
content: Sounds like a brown-out reset or (less likely) stack over/underflow reset to me...To get meaningful information out of the RCON register, you need to manually set the POR and BOR bits after checking the RCON register at boot-up.Procedure is as follows: Power-on > check RCON register > RCON = 00111111This way, when the PIC randomly reboots next time, checking the RCON register will tell you what's going on. If the POR and BOR bits are clear again, it's a power-on reset. If POR is set and BOR is clear, it's a brown-out reset (but only if you're using the internal voltage regulator for VDDCORE). See section 5.0 (RESET) in the datasheet, and specifically section 5.4.1. (Ref. the latest DS from Mchip's website).It's also possible it's a stack overflow reset, although at 31 levels deep it's unlikely. I use MikroC, not MikcoB, but the library functions can sometimes use a lot of stack overhead, especially if interrupts are enabled. Look at the 'Functions Tree' section under View > Statistics in the compiler. You can see the function dependencies - ie how many calls within calls you have. Don't forget to add one for the interrupt routine.Also, always read the errata. Very important! There's stuff in there about the EUSART and oscillator. A mis-configured oscillator/PLL could cause this. If you have an early chip revision you need to pay attention to every point listed. Seehttp://ww1.microchip.com/downloads/en/DeviceDoc/80503e.pdfYou also need to check the interrupt routine is doing it's context saving correctly. You'll need to do this in the disassembly listing (View > Listing). I had a problem on an older version of MikroC where the interrupt routine was not saving context correctly (compiler issue). The PIC does hardware context saving in some circumstances, but might not. See datasheet page 138.Also, on page 119 of the datasheet it says:NOTE - Do not use the MOVFF instruction to modify any of the Interrupt Control registers while any interrupt is enabled. Doing so may cause erratic microcontroller behavior.Check the disassembly listing to see if any of the INTCON, PIR or PIE registers are modified using this instruction.Failing all that, plough through the disassembly listing to see if anything looks unusual. But if you're not familiar with the PIC architecture, that might be tricky.Good luck!

author: richcj10
author_rank: Unknown
timestamp: December 29, 2012, 05:13:45 pm
content: Thanks Lewis. I shall go over the this tonight. I am using a 16 Mhz crystal with no PLL. One thing I have learned is to look at the errata. Dave tought me that.

author: mamalala
author_rank: Unknown
timestamp: December 29, 2012, 11:25:00 pm
content: Quote from: richcj10 on December 29, 2012, 05:58:03 amSo strong that you have to use BASIC on that poor µC? (Hint: C is just fine for PIC's. Especially the PIC18 series, since that architecture is optimized to be used with C) For some project that allegedly is under some NDA even (meaning that you want us to help you without even showing what you are doing because of the supposedly big $$$ in it)?Haha ...Greetings,Chris

author: richcj10
author_rank: Unknown
timestamp: December 30, 2012, 12:08:19 am
content: Quote from: mamalala on December 29, 2012, 11:25:00 pmMy client wants the project done in basic. He doesn't understand / like C.

author: richcj10
author_rank: Unknown
timestamp: December 30, 2012, 03:03:07 am
content: It is responding with 00111111 during serial resets.

author: richcj10
author_rank: Unknown
timestamp: December 30, 2012, 05:14:53 am
content: i have the code to a point that You can see it.It is attached B/C it is too large.

author: richcj10
author_rank: Unknown
timestamp: December 30, 2012, 06:07:50 am
content: I did some testing with print outs of the code to tell me what was going on and here is what i found:Code:VIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBK?cVIBKBRBKVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBR63Boot DoneBRVIBkVIBRVIBRVIBRVIBRVIBRVIVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBRVIBR63Boot DoneBRVIBkVIBRVIBRVIBRVIBRVI?c = chargingVI = vin fcn calledBR = Bat readBK = call return susesful from charging codeBk = call return susesful from time based int. codeIf you take a look at a reboot (boot done) you notice the that VI and BR are being called but they are not being called by the two places that they are normally being called at. weird....Now, I need to figure out why...

author: notsob
author_rank: Frequent Contributor
timestamp: December 30, 2012, 06:53:39 am
content: Perhaps try writing it in C and use a different compiler (ie mplab) just to eliminate the compiler you are using

author: amyk
author_rank: Super Contributor
timestamp: December 30, 2012, 07:23:55 am
content: To rule out a stack overflow check the STKFUL bit in the stack pointer after a reset. A POR will clear it, a stack full reset will set it.

author: richcj10
author_rank: Unknown
timestamp: December 30, 2012, 04:57:42 pm
content: I am reading the reset and overflow like this:Code:rseting = RCONrsetg = STKPTRRCON = %00111111I am getting a 0 backWhen I read STKFUL ( I read it during the problem part of the code where it charges the battery)I am getting back a 7 or 00000111I don't think this is a problem?

author: lewis
author_rank: Frequent Contributor
timestamp: December 31, 2012, 12:33:13 am
content: Quote from: richcj10 on December 30, 2012, 05:14:53 amYou have two instances of "rseting = RCON" in your code, get rid of the one under the init(). The second one reads RCON after you've written to it which overwrites your rseting variable with the overwritten value, not the original RCON value.

author: richcj10
author_rank: Unknown
timestamp: December 31, 2012, 03:36:00 am
content: fix and no change...

author: amyk
author_rank: Super Contributor
timestamp: December 31, 2012, 07:56:46 am
content: Quote from: richcj10 on December 30, 2012, 04:57:42 pmThat is fine but you need to read the value after a reset, since that's when the STKFUL bit will be set if the stack overflow.

author: mamalala
author_rank: Unknown
timestamp: December 31, 2012, 02:10:53 pm
content: Quote from: amyk on December 31, 2012, 07:56:46 amBut then the problem is: what does the compiler generate as startup-code in it's runtime library. It might well be that it already overwrites all that stuff before passing control over to the main program.Greetings,Chris

author: richcj10
author_rank: Unknown
timestamp: January 01, 2013, 04:56:55 pm
content: I don't think that is true. When I program the MCU, I get 00111100. On a normal reboot I don't. This tells me the compiler is not touching this.I have added notifications when a sup fcn runs. It looks when a reset condition occurs it runs the first three sub fcn's in quick repetitiveness about 5 times. I don't know how the code could do this?

author: Niklas
author_rank: Frequent Contributor
timestamp: January 01, 2013, 11:36:09 pm
content: Do you have any spare pins? If you have, then you can try to add some debug signals that you can trigger on with an oscilloscope or logic analyzer.- One I/O for a startup pulse that is also used as trigger for the oscilloscope.- Other I/Os for separate functionsThe oscilloscope should do a one shot trigger with the trigger point set to about 2 divisions from the right side of the display. By selecting the timebase right you can then get the history. Will the same function crash all the time or is it more random? Kind of oldschool but it works without to much penalty and without a debugger and its related code.

author: darrylp
author_rank: Regular Contributor
timestamp: January 02, 2013, 12:13:13 am
content: Standard DOS output of serial data will be 13,10 rather than your 10,13.Nothing to do with your problem, but end company might like this to follow standards.

author: richcj10
author_rank: Unknown
timestamp: January 02, 2013, 08:33:36 pm
content: It was bad hardware. I replaced the PIC with a PIC18LF46K22 and it worked fine. go figure.

author: Niklas
author_rank: Frequent Contributor
timestamp: January 03, 2013, 12:36:01 am
content: How can you rule out SW bugs so sure if you dont test it with another PIC of the same type? The K and J types are different and now also an LF type. It might be something that is not initiated correctly or an errata on one type of PIC.

author: richcj10
author_rank: Unknown
timestamp: January 03, 2013, 01:31:44 am
content: The layout of the board was for the PIC18LF46K22.We had go to the PIC18F47J13 for more space. The bad part of this chip is it had the Vcore pin.We had the pin bent up with a 10uF attached. I felt that this was causing issues.