| View previous topic :: View next topic |
| Author |
Message |
E_Blue
Joined: 13 Apr 2011
Posts: 417
|
| How to know why WDT is barking? |
 Posted: Sat Dec 16, 2017 6:58 pm |
 |
|
There's any way to know what part of the code is making WDT to bark?
I know that the WDT is barking time to time but the code is too long.
There's any register that saves the last PC (Program Counter) before the WDT barks or something similar?
_________________
Electric Blue |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Dec 16, 2017 11:36 pm |
|
|
You could put marker bytes in the code with putc() statements, using the
hardware UART. If possible, use a high baud rate such as 115200.
Start with your main loop as shown below. This will show the progression
of your program in the terminal window. See if it always restarts in the
same function.
If it does, then put marker bytes within that function. Or, just closely
look at the function.
| Code: |
void main(void)
{
print("\n\r\n\rStart: ");
while(TRUE)
{
putc('A');
function1();
putc('B');
function2();
putc('C');
function3();
putc('D');
function4();
}
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Sun Dec 17, 2017 1:07 am |
|
|
The other way is to use a marker.
| Code: |
int16 marker;
#define mark(x) bit_set(marker,x)
//Then at the start of your main
if (restart_cause()==NORMAL_POWER_UP)
marker=0;
//At this point, 'marker' has the bits set you have marked
//before the restart.
mark(1);
function1();
mark(2);
function2();
mark(3);
function3();
mark(4);
function4();
|
Critical thing to be careful of is the minima. On some (a lot) of the older PIC's the watchdog timeout is very inaccurate. If you have the watchdog set to (say) 1 second, and then have a half second delay, you instinctively think "can't trigger", but checking the data sheet the minimum time for the same setting may well be only perhaps 400mSec... |
|
|
E_Blue
Joined: 13 Apr 2011
Posts: 417
|
|
| Posted: Sun Dec 17, 2017 1:58 pm |
|
|
Thanks for the ideas. 
_________________
Electric Blue |
|
|
E_Blue
Joined: 13 Apr 2011
Posts: 417
|
|
| Posted: Mon Dec 18, 2017 11:48 am |
|
|
I just want to tell you that I found the bug.
It was a 8 bit variable that must be declared as 16bit variable so it can be compared against another 16bit variable.
| Code: |
char count=0;
long bytelimit=0x4000;
do
{
count++;
}while(count<bytelimit) //<--count is 8bit and never going to be bigger than bytelimit. |
The curse of copy&paste. 
_________________
Electric Blue |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Dec 18, 2017 4:32 pm |
|
|
| Did the techniques that we gave you, help you to find the bug ? |
|
|
E_Blue
Joined: 13 Apr 2011
Posts: 417
|
|
| Posted: Tue Dec 19, 2017 1:57 pm |
|
|
| PCM programmer wrote: | | Did the techniques that we gave you, help you to find the bug ? |
The program uses both USARTs so I was thinking in to use USB instead but first I tried by just debugging and, since the WDT barks after 8 seconds, I just halt the debug when I see that the program get halt and check where the program get looping forever; and it works.
The marker at RAM level I'm not sure if works or not because after the WDT I have not clear if the GPRs are reset to 0 or keep the last value.
Also CCS compiler have some init code before the code reach the main and I have no 100% clear how it works.
_________________
Electric Blue |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Tue Dec 19, 2017 2:12 pm |
|
|
| Quote: |
The marker at RAM level I'm not sure if works or not because after the WDT I have not clear if the GPRs are reset to 0 or keep the last value.
Also CCS compiler have some init code before the code reach the main and I have no 100% clear how it works.
|
Global variables, that are not 'static', are only initialised if the code says to do so (or you have zero RAM selected).
Static variables are zeroed.
So a global variable as I show will not be initialised.
In order to start it at zero, the routine I post will clear it if the chip has done a normal reset.
This is a very important behaviour, since it allows you to have variables that are initialised, but retain their value after a watchdog reset.
This potentially allows a chip to be programmed to 'carry on' with values set up as they were after a watchdog reset. |
|
|
guy
Joined: 21 Oct 2005
Posts: 297
|
|
| Posted: Sun Dec 24, 2017 3:26 am |
|
|
| E_Blue wrote: | | The program uses both USARTs |
Just the other day I suggested to use PPS with an available pin, if you need an unplanned debug UART, assuming you have PPS on your chip. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Sun Dec 24, 2017 3:44 am |
|
|
| Remember also that for a debug transmit, a software UART is normally perfectly usable. Especially if you use a nice high rate, so that interrupts can be disabled for a moment while the character transmits. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
