MC9S08PA60 Watchdog Refresh Issue

[ncci4phil]

I am quite experienced with older S08's, but new to the PA-series. When I try to refresh the watchdog timer, as soon as I write '$A6' to WDOG_CNTH my MPU does a reset. Even if I write 'C5' to WDOG_CNTH as an attempt to unlock the PA60, it resets and I lose Comms with both Coldwarrior and P&E Micro's debuggers.

I've tried both 8-bit '$A6' writes (LDA/STA writes) and 16-bit '$A602' writes (LDHX/STHX writes). Writes to WDOG_CS1 and WDOG_CS2 seem to work just fine. I have over a hundred pages of code, and this is the one issue I and others can't understand what we may be doing wrong.

I even wrote a basic and simple 'toggle an output' program and the same issue shows itself.

Thanks,

Phil

[Pablo_Ramos]

Hi @ncci4phil,
We realize that you have another support ticket regarding this matter, we will contact you on the ticket.

[Alex_ODonnell]

After talking with Phil outside this thread, I looked for reference documentation for an assembly language example given for the MC9S08SA60. I didn't find one online, but I did find one in the examples bundled with Codewarrior 11.

I did a live debug session and we found two issues going on.

1. Debug methodology
2. Code issue

1. Single Step to be used with caution.

We walked through how he was debugging in general by using the Codewarrior sample and found an issue with his technique.  Phil was single-stepping through his board's initialization code, a very common practice for config set up. From what I could hear (phone call, not shared screen) on the second write to WDOG_CNT to unlock, there was an interrupt causing a reset. I had Phil set up a breakpoint after the unlock sequence and "run to breakpoint" rather than single-step. This got us past the reset.

We believe that we cannot single-step through the code to unlock or feed the watchdog as those sequences need to happen within a certain number of clocks.  Single stepping gates CPU actions to one instruction at a time and does not gate the clock to the watchdog module.

So, we got past a user error and then were left facing another problem.

2) Phil's fixed code ended up looking like this

      LDHX  #$103F            ; Point to the last RAM Address plus 1 (actually, keeping it in Direct Address space)
      TXS               ; Transfer address to the stack
;
      SEI         ; Set IRQ Mask
;
;
;  WDOG: Now we need to unlock the WDOG...
;
      LDHX  #$C520            ; First sequence to unlock WDOG
      STHX  rWDOG_CNT
      LDHX  #$D928            ; Second sequence to unlock WDOG
      STHX  rWDOG_CNT
;
;
;  Now write to all registers within 128 bus cycles after unlock sequence...
;
      LDA   #$00              ; Disable WDOG
      STA   rWDOG_CS1
      LDA   #$00
      STA   rWDOG_CS2
      LDA   #$FF
      STA   rWDOG_TOVALH
      STA   rWDOG_TOVALL
      LDA   #$00
      STA   rWDOG_WINH
      STA   rWDOG_WINL
;
;
;  Now refresh the WDOG...
;
      LDHX  #$A602            ; First sequence to feed WDOG
      STHX  rWDOG_CNT
      LDHX  #$B480            ; Second sequence to feed WDOG
      STHX  rWDOG_CNT
;

 as opposed to that in the original ticket which was 

	LDHX	#$0100		; Point to the last RAM Address plus 1
	TXS			; Transfer this address to the stack
;

	SEI		; Set IRQ Mask


	LDA	#$A6
	STA	$3032	; tWDOG_CNTH
	LDA	#$02
	STA	$3033	; tWDOG_CNTL

	LDA	#$B4
	STA	$3032	; tWDOG_CNTH
	LDA	#$80
	STA	$3033	; tWDOG_CNTL


	LDA	#$00
	STA	$3030	; rWDOG_CS1

You'll see a few changes, such as moving the stack base to match the CW example, but that was not the issue.

You will see the addition of the unlock sequence despite the fact that we were acting ASAP after the reset and should have been within the "write once" window of clocks at the start of time. This additional unlock allowed us to start setting up the WDOG configuration, where as before, we were triggering an access violation event.

The code will ultimately use watchdog but is for now disabled to facilitate testing and debugging of the main code.

I'm still working with Phil as he and I are both new to the updated watchdog module used in the MC9S08PA60, coming from older S08 devices in Phil's case, and, in my case, returning to S08s after a decade working on Atmel and ST 32 bit Arm devices.

[Alex_ODonnell]

Phil,

I just noticed this other thread here on the board discussing similar issues https://community.nxp.com/t5/Kinetis-Microcontrollers/watchdog-program-S9KEAZ128AMLH/m-p/458272.  It might contain a hint for you.

Alex

Also 

[ncci4phil]

Good find. I just tried it: Writes to WDOG_TOVALH/TOVALL/ CS1.CS2 are ok. Write to WDOG_CNTH yield MPU Reset.