Hi to all,
in an our implementation, operating and marketed for several years, the application SW uses the watchdog to generate a reset which sends in monitor mode the used microcontroller (DSP56F807PY80E), this methods is used for remote reprogramming of the FLASH EPROM.
In a last production batch, however, this mechanism works erratically: the cards, received the command to monitor, enter into this mode after a time limit which is sometimes of milliseconds, or, in other times, of hours.
Below is reported the oscillogram (Fig. 1) of an OK case.
The top part of the screen is 500 ms per division;
The lower part is the zooming to 50 ms per division of the part shown by the white rectangle.
Fig.1
The yellow trace is from the test-point TP30, used to indicate the time when you decide to let drop the watch-dog, as in the piece of code below:
SYS.STS|=4; // Cause Watch Dog failCOP.CTL=0xE;TP30=0;while(true)TP25=!TP25; // Show WD waiting time
By means of the green trace (TP25) you can see the waiting time of the fall of WD, which ends with a reset (reset out is the red trace) also evidenced by the fact that the outputs of the yellow and green traces are placed in three-state.
When the microcontroller starts, the reset vector points to the code below:
Startup:bfset #M_32bit_compares,omr ;debugger will override this if debugger option is onmove #-1,x0move x0,m01 ;set the m reg to linear addressingmove hws,la ;clear the hardware stackmove hws,la;init registersmove #0,r1move r1,x:FIPRmove r1,x:FCOP;setup stackmove #F_stack_addr,r0 ;get stack start addressnopmove r0,x:<mr15 ;set frame pointer to main stack topmove r0,sp ;set stack pointer toomove #0,r1move r1,x:(r0);setup the PLL (phase locked loop)bfclr #2,X:FGPIOD+3 ;T25_PER=0bfset #2,X:FGPIOD+2 ;T25_DDR=1bfset #2,X:FGPIOD+1 ;T25=1 move #pllcr_init,x:FCLKGEN ;set lock detector on and choose core clockmove #plldb_init,x:FCLKGEN+1 ;set to max freqmove #wait_lock,x0 ;set x0 with timeout value;timeout handles simulator casepll_test_lock: ;loop until PLL is locked or we reach timeout limitdecw x0 ;decrement our timeout valuebfclr #2,X:FGPIOD+1 ;T25=0tstw x0 ;test for zerobeq pll_timeout ;if timed-out, proceed anywaybfset #2,X:FGPIOD+1 ;T25=1brclr #pllsr_init,x:FCLKGEN+2,pll_test_lockpll_timeout:
You can see how, in the green trace, there is evidence of the waiting time of stabilization of the PLL with a group of transitions wich is about, in this case, 230 ms after the reset.
In the following oscillogram (fig. 2), relative to a second procedure for entering monitor mode, is known as the time that elapses between the reset and the wait loop of the PLL is greater (345 ms), but still reasonable:
Fig.2
In the following oscillogram (Fig. 3), on a third third procedure for entering monitor mode (this time it failed), we see how the software is not yet restarted at the end of the screen (3.7 seconds after the reset).
Note that this oscillogram, as stated in the screen header, is of 19:49:59.
At 20:11:07, the next time indicated in the oscillogram (fig. 4), i forced the shutdown of the oscilloscope, and the start of the software had not yet had.
Fig.3
Fig.4
...someone can solve this problem?
Paolo
