PIC18 - reset in middle of running code

[richcj10]

fix and no change...

[amyk]

I am reading the reset and overflow like this:

Code: [Select]


rseting = RCON
rsetg = STKPTR
RCON = %00111111


I am getting a 0 back
When 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  00000111
I don't think this is a problem?

That 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.

[mamalala]

I am reading the reset and overflow like this:

Code: [Select]


rseting = RCON
rsetg = STKPTR
RCON = %00111111


I am getting a 0 back
When 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  00000111
I don't think this is a problem?

That 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.

But 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

[richcj10]

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?
 

[Niklas]

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 functions

The 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.

[darrylp]

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.

[richcj10]

It was bad hardware. I replaced the PIC with a PIC18LF46K22 and it worked fine. go figure. 

[Niklas]

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.

[richcj10]

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.