COP - related questions

[admin]

Hello,

I have two questions regarding the COP:

1. I'll quote something from the COP Tutorial then I'll write my question:

"COPCTL (COP Control Register) is located at address $FFFF and overlaps with the CPU Reset Vector.
Writing ANY value to address $FFFF clears the COP counter and the SIM counter. This prevents a COP reset and starts a new timeout period"

So my question is: How to write a new RESET ADDRESS ? Is this possible during program execution if the program is supposed to change the Reset Address according to some environment changes ?



2. System Protection Methods:

It's suggested not to refresh the COP from within ISRs (Interrupt Service Routines). What if execution time of an ISR is undetermined, or lasts longer than the COP timeout period ?


Best Regards,
Roger Tannous.

[soac]

help !!!!!

I TRIED TO RESET THE COP

SRS_COP = 1;

I CAN __RESET_WATCHDOG ALL OVER THE PLACE AND IT WORKS.

I THINK  I'M RESETING THE COP, EXECPT IT GOES BACK TO MY_MAIN LOOP AND REBOOTS.

I PUT THE FILE INTO FULL CHIP SIMULATION AND THE FILE WORKS???

I WAS GETTING A COP ERROR, BUT WITH THE NEW COP RESET, THE ERROR IS GONE.

PS. WHAT IS A QUICK WAY OUT OF A LOOP IN FCS???

[peg]

Hi soac,

I am not sure I am understanding you or not.
If your running in the simulator, it should tell you that a COP reset has occurred and halt. If its resetting and you get no messsage, then it is probably some thing else.
To test this, temporarily put an infinite loop in your progamme with out a COP reset and see what happens.




Message Edited by peg on 2007-12-15 10:04 AM

[soac]

I PUT AN INFINTE LOOP IN MY PROGRAM.

THE  FCS JUST LOOPS AT THE INFINITE LOOP.

IT DOES NOT GIVE A  COP ERROR.

THE COP APPEARS TO BE WORKING

I MUST HAVE A FLUX PROBLEM

IF THE COP SEES A HIGH CURRENT, I SHOULD GET A RESET.

THANKS FOR YOUR INPUT.

[soac]

I WAS GETTING AN ERROR AFTER PUSHING A PUSHBUTTON.

I HAD A 220 OHM RESISTOR TO VDD AS THE HIGH SIGNAL.

I GOT A COP ERROR, SO I THINK !!!!

I REPLACED THE 220 OHM RESISTOR WITH A 10K OHM RESISTOR.

WHEN I PUSHED THE PUSHBUTTON ALL WENT WELL.

I AM NOT SURE WHAT THE PROBLEM WAS, EXCEPT IT WENT AWAY ????

I GUESS THE COP IS WORKING AND IT DETECTED A HIGH CURRENT.

SO THE COP SENT A MESSAGE TO THE COP CIRCUIT AND REBOOTED....

THAT IS WHAT I THINK, THERFORE THE COP IS WORKING

I THINK THIS FORUM IS GREAT AND FULL OF GOOD INFORMATION. I HAVE SOLVED

SIX PROBLEMS SO FAR.!!!!!

[Alban]

Hi Roger,

1. To change the reset address, you need to do Flash Programming. On the 8 bits, you will have to run your software from oustide the Flash memory block (like copy a piece of routine and execute from RAM).
This routine will first have to erase the whole page and then have to reprogram all vectors of the page.
Note that it is not possible to do if Flash Block Protection Registers is enable on the area.
All so called "bootloaders" are doing this operation to change the firware of a MCU they receive via SCI, SPI or CAN...

2. An Interrupt by its essence is supposed to be quick. The Software designer has to have an ISR which is short enough to be executed without a COP.

The COP is here to avoid the code to execute from anywhere and do anything. If the CPU executes code from anywhere, there is little chance the code it executes will refresh the COP... It could be stuck in a infinite loop.

Well,  if you refresh the COP in an ISR which can happen at anytime, it means your soft will stay stuck forever without a small hope of recovery...

Hope this helps,

Cheers,
Alban.

[admin]

I'm just reading the HC08 Tutorial and some questions just raised up in my mind

[rhinoceroshead]

Although I've never done it before, I would imagine it would be possible to write to the vecors just like writing to flash.  But it would be easier to make your main entry point branch to two different places depending on the contents of some variable or register.  Reset doesn't affect memory contents (registers yes) so a variable you had before reset will still be there afterwards, with the exception of a POR of course.

It's good form to make your ISRs as short as you can possibly make them so they don't interfere with the other ISRs or the main thread, so if you're doing that then you shouldn't need to clear the COP in an ISR.  But I would say anytime you go into a loop that is of undefined length, you should reset the COP inside the loop even if it's in an ISR.  But the only such loop I can think of is an I/O wait loop, which you shouldn't ever need to do in an ISR, because the I/O you're waiting for might as well be the trigger for another interrupt.  I guess it depends on the application.  You may also be re-enabling interrupts inside an ISR to allow a higher priority interrupt to take over.  If that happens too often, then you could get a COP reset if the ISR doesn't clear the COP counter.

Is this out of curiosity or do you have a specific situation occurring?

[peg]

Hi all,

There is one sentence in rhinoceroshead's reply that has reminded me of something that has bugged me for a while.

"You may also be re-enabling interrupts inside an ISR to allow a higher priority interrupt to take over."

Can you do this?

Also, on interrupt priorities. Manual says:

"Once an interrupt is latched, no other interrupt can take precedence, regardless of its priority"

So when is an interrupt latched? can't be straight away as no priority scheme can work.

Does this mean that if two modules generate an interrupt during the same instruction that the first one wins regardless of priority. And only if two or more interrupts occur while the I bit is clear then they are prioritised?

If anyone can guide me to a document that explains this I will accept a reduction in that cheques value.

BR Peg

[rhinoceroshead]

Here is how I understand it:

During the execution of some instruction, say LDA #$00, suppose you get a timer interrupt.  Then a few nanoseconds later - but still while executing the load instruction, you get an IRQ interrupt.  At some instant towards the end of the load instruction, the arbitration will occur, and the IRQ will win even though the timer interrupt arrived first.  This is what the hardware interrupt priority does for you (and anytime the I bit is set, once it is cleared the hardware arbiter runs to determine which one to run).  From my perspective, it's not that valuable because both interrupts are usually not very likely to occur within the same fraction of time that it takes to execute a typical instruction or ISR.  But once the arbitration is done, the CPU is fully committed (latched) to the IRQ and starts stacking the registers, setting the I bit in the CCR and loading the new program counter value.  That takes a lof of cycles to do - and it can't be interrupted, but then once the CPU begins executing the first instruction of the IRQ ISR, it has absolutely no way of knowing that it's executing an ISR.  If you clear the I bit in the IRQ ISR, it will see that the timer interrupt is still pending and start stacking the registers again and loading the timer vector address.  So if your program uses two interrupts and you want one to have actual executing priority over the the other one, you can re-enable interrupts at the beginning of the lower priority ISR, but not in the higher priority one.  You have to be careful in this situation, because it then suddenly becomes possible for that timer interrupt to interrupt itself, and you can deplete your stack if it cascades too long.  That's another good reason to keep the ISRs short.  One other thing I should mention - if you re-enable interrupts in an ISR before you lower the flag on the module that triggered the interrupt, you WILL have that ISR interrupt itself until your stack is gone and your program will crash.

Message Edited by rhinoceroshead on 04-28-200608:36 AM

[rhinoceroshead]

Oh, back to digitalDNA's original post.  Since the COP resets your machine - which sometimes is just as bad as having the thing get stuck in a loop, I believe there are no hard and fast rules about where you should and shouldn't clear the COP counter.  That's just me though.  It is a tool that is there and you can use it as you please or not use it at all.  Runaway code can actually damage your hardware, however, if it does something like set a port to output when there is a low impedance signal on that pin.  Your microcontroller's port might try to push the pin down to 0 volts when there is the output of a comparator there trying to push it up to 5 volts.  If you didn't put a resistor to limit the current there then you will most likely ruin the port on your microcontroller.  At the very least, you will notice your microcontroller getting hot and perhaps smelling funny.

One thing you could do is let the COP counter be an I/O timeout.  You could set a variable in memory to indicate you are waiting for a response from some external device and then write an infinite loop while waiting.  If the signal never arrives, your chip will reset from the COP and your main routine can check the location of that variable you set as a flag and route to the proper function from there.

To be honest, I never use the COP.  But I've never done anything professionally, so maybe I shouldn't be talking here.  :smileyhappy:

[peg]

This is probably my best guess as well. Just wanted it confirmed.

Also your sentence I quoted is probably not exactly correct in that once you re-enable ints from within an isr the arbitration of the current int is done so it will allow higher AND lower priority ints to run within the first one.

Peg

[rhinoceroshead]

Yes, Peg, I stand corrected.  You also allow lower priority interrupts to occur when you do that.  But if you have one interrupt that you want to have priority over all others, you can re-enable interrupts in every ISR except that one and then it will effectively have higher priority.  Do you accept VISA?

By the way, the S12X chip actually lets you set a 3-bit priority for each interrupt and it has a 3-bit mask in the CCR register to let you clearly define which ISRs can interrupt any given piece of code.

[rocco]

This is an interesting discussion, both the COPS portion and the nested-interrupt portion.

Here is my $.02 about COP, fully depreciated to $0 over the years:

Alban's point that reseting the COP in an ISR would fail to recover stuck code in the main loop is a valid one. But what if you also need to recover from an interrupt that stopped occurring regularly. For me, this is more important, since my main loop is simply a call to a task scheduler and a WAIT instruction. The tasks are then queued by interrupts which are the engine that drives my firmware.

So I implement multiple COPS in software. Each regular interrupt does a bit-set to its assigned bit in a soft-cop byte. My lowest priority task (called "Blink" because it also flashes a heartbeat LED) checks all of the soft-cop bits, and resets the hardware COP only if all soft cops are set. It then resets all of the soft-cop bits.

This buys me two things. First, I can assign a soft-cop bit to anything that I feel is critical, whether it is an ISR or a task. Second, since the hardware COP is only cleared in the lowest priority task, I can insure that no one task is usurping all of the cpu.

The cost of this is one byte of page-zero ram, one BSET instruction per critical ISR or task, and a small COP-reset routine in "Blink" (15 cycles), which is queued to run on every timer-overflow. It's pretty low-cost for insurance.