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
Hi @ncci4phil,
We realize that you have another support ticket regarding this matter, we will contact you on the ticket.
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. 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.
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