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.
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
Message Edited by rhinoceroshead on 04-28-200608:36 AM
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:
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
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.