Watchdog vector issues

Gunde · ‎08-12-2011

Hi all

i´m working with MC9S12A256 and i´m trying to resolv a problem with the controller.

To do that i have started the watchdog and configured the vector to jump to a routine there i want to save the contents pushed to stack just as the controller jumps to that vector.

I have tryed many ways as:

movb 0,sp,SaveCCR (SaveCCR is a ram location)

ld a,0,sp

staa SaveCCR

But whatever i do it frezees the controller and i can just start it with a hardware reset.

This problem just occur if i try to use any fatches to ram.

If i do like this: (nothing i can use to solve my problem)

movb #10,SaveCCR

It works just fine.

Anyone having any idea what it can be?

I want to have a copy of the value of some ram locations but this doesnt seemes to be possible. Have tryed many different approaches.

Best regards. Gunde

kef · ‎08-12-2011

Similar question was asked here or on 68HC12 mailing list long time ago. I'm not sure, was it about illegal address reset (available on S12X) or COP watchdog reset, but the problem was that stack pointer (SP) is reset to 0 (or maybe 0xFFFF, I'm not sure) on MCU resets. So you can't say were stack pointer was pointing before COP timeout. Unfortunately. Try checking it yourself.

Gunde · ‎08-13-2011

Thank you very much kef

Ok. I thought I had a great idea

But there is one more thing that puzzles me.

I have, in the watchdog reset vector, placed this instructions:

movw #Pattern1,VariabelWord1

movw #Pattern2,VariabelWord2

just to see from where I enter my main routine, and it looks to work just fine.

But if I add something like this:

ldaa ByteSomeWhereInRam

staa ToSomeOtherPlaceInRam

Very often the core seems to freeze down completely and stops executing.

Sometimes the routine works one but not two times and this makes me very frustrated :-|

I meen, it isn't so very complicated instructions, I'm not even using SP, but out of some reason it doesn't work and it makes me feel insecure about the controller.

Could it be some kind of uncertain state in the core that makes it go wild?

Of course I have tried this by jumping to the routine directly from main and it works as it is supposed to but not then triggered by the COP.

Very thankful for any ideas.

Br. Gunde

kef · ‎08-13-2011

It is not clear what the all process is. If your LDAA-STAA sequence is at top of COP routine, then what happens next and how do you assume it gets frozen or doesn't execute too few or too many times? If you assume that COP routine should be triggered again and again, then keep in mind that COP reset resets all hardware and COP gets disabled and should be initialized again to make it working.

Gunde · ‎08-13-2011

Thanks again.

I understand I have given a very short description before.

Now, one more comprehensive.

VECTOR0 #AdressToMain ; Normal starting point

VECTOR2 #AdressToWD_Service ; COP reset entry

WD_Service:

movw #PatternWord1,RamWord1

movw #PatternWord2,RamWord2

; If I put some more instructions as described before here I´t doesn´t´t´t work

bra Main

Something else of my program

Main:

lds #AdressToStackArea

jsr InitSystem InitSystem: Init Watchdog

Init Everything else

as 3 SPI

as 2 SCI

as 1 IIC

as RAM

rts

MainLoop:

Refresh Watchdog

DoEverything else needed to be serviced

bra MainLoop

When I test the COP I have just put a counter inside the main loop and the it reaches 0 I start an infinite bra $ to trigger the COP.

I know that the system gets frozen in 3 ways:

1) I have a LED flashing at 2 Hz. That stops

2) I use one of the SCI;s for getting a "start up"-string and that doesn't get send

3) It doesn't respond to any system codes issued to the SCI

If I, takes away the instructions, mentioned before. I.e. ldaa staa It works just fine

If I jump directly to the WD_Service, without reset it works just fine

If the WD reset ist triggered by the COP it doesn't work, if I have the instructions in it

The main issue right know is to try to understand why this is happening.

We have already distributed around 1250 such systems out in the world, after a testing period (not the COP-reset ) of more then 14 months in 42 installations, and we have just recently run into this problem in some installations in Poland and USA.

Of course, normally the COP shouldn't trigger, but it is anyway a good way to solve a problem at first, during the time it takes to find the real source of the firmware weakness.

Br. Gunde

kef · ‎08-14-2011

It's interesting. I think that you should enter service request for this problem here . Or, if you can remove all sensitive intelectual property leaving maybe just LED blinking, and if it still won't work (unlikely), then I'd like to look at this code.

It is not clear, are you using COP resets in produced units to reset MCU periodically? Or is it just for test purposes? I hope you know that COP and CME vectors can be disabled and revectored to main vector at 0xFFFE 1) having large enough capacitor on /RESET pin or 2) using supervisor chip with push button function. This happens because on MCU internal resets /RESET pin is pulsed low and sampled immediately to determine if it was external or internal reset. Both, capacitor and S12 incompatible supervisor chip make MCU unable to determine if reset was internal or external. Didn't hardware guys or suppliers change something and units stopped working?

Gunde · ‎08-15-2011

Thank you kef.

I will be back but first I will try to understand the problem a bit more in detail.

Writing a simplified program I think will be a good idea, because right now it´s hard to get a grip on it.

Right now I'm using a lot of peripheral units, up to 6 interrupt sources, so I will make in simpler and try to pin point when it happens.

Br. Gunde

Watchdog vector issues

Watchdog vector issues

General