1) See rule 5, ie check you have the required stack space.

2) Make sure register reads are not being performed on write only registers. N.B. some instructions are implemented internaly as a rmw (read modify write) cycle. list below of problem instructions when used with write only registers.

AND
OR
XOR
TST // this is implemented internaly as a read-modify-write (RMW) instruction

mov A, reg[write_only_register]

N.B. if using C code be aware some instructions will compile down into one of the above.

TIP: always mark any use of write only registers with **** WOR **** or similar. This prevents accidental code changes later when you have forgoten it's write only.

3) Save all registers that are used inside an ISR. Exit ISR's with RETI in assembler code.
N.B. If your ISR performs a call or a lcall to another function then the other function is not to be exited with an RETI instruction. See examples below

eg1.

 GPIO_ISR:: ;designer generated assembler file
 
 lcall my_code ;this is assembler code only, C code won't work like this
 reti ;this is the only valid reti instruction
 
 my_code::
 
 bla....bla code
 ret ;do not place reti here as its implemented above.

the code format above CANNOT work with C code. The reason is C requires to be told if my_code() is an ISR. If it is defined as an ISR then the compiler does TWO things.

1. It preserves all used registers on the stack to avoid corruption of data.
2. It exits the function using an RETI instruction.

If using C code use the code below.

eg2

 GPIO_ISR:: ;designer generated assembler file
 ljmp _my_code ;note under score(_) before function name.
 ;no return required as the above is a jump instruction

 #pragma interrupt_handler my_code

 void my_code()
 {
 bla..bla.. code
 
 }

There are alternative approaches to handling ISR's, to be honest they are better but they require modifying boot.tpl so I'll leave them out. We are trying to get rid of problems by making things simpler rather than making them complicated and optimised. If writing in assembler place all your code in the generated file and perform no external code if possible for maximum efficiency.

4) WDT and EEPROM write requires caution. Just prior to using the EEPROM write function, clear the WDT. If the WDT is set to to anything other than 8Hz then you must also change the sleep timer to 8Hz. The reason is that the EEPROM write is time critical and requires that the interrupts are disabled, it also takes around 10mS to execute. This means the WDT won't be refreshed for 10ms or so. After the EEPROM write perform another WDT clear. The second is not always required but ensures the WDT refresh cycle will be met. After the write is performed the sleep timer can be reset to refresh the WDT at the nominal rate you require.

5) If using ADC's that use ISR's to update the ADC value and performing EEPROM writes, be aware that the ADC interrupt latency may not have been met and the next conversion may be invalid. Either flag each write and discard the ADC value or interleave the two such that they never overlap. Each approach has it's advantages and disadvantages. It's your job to decide what's best for your application and ONLY you can decide that.

6) The SAR6 ADC stalls the CPU core for the duration of the conversion (see rules 1&2!). This implies three things:

1. The WDT if used may not meet the required refresh rate.
2. Any other ADC's that use ISR's may not have their interrupt latency met.
3. If using interrupts the SAR conversion may be interupted part way through the conversion, result: discard the conversion. You can bracket the SAR conversion by disabling interrupts but this makes points 1&2 above even more affected. Convert as fast as you can and you should have no problems, remember rule1 and don't exceed the clock rate as described in the data sheet.

N.B. Contrary to normal ADC reading rules the slower the clock to the SAR the worse the problem becomes! If this is a problem increase the clock to the SAR and/or implement the solutions to points 4&5 above. With a regular CPU slowing down the sample rate to a ADC will give more CPU time. With the PSoC and the SAR6 slowing down the SAR clock will also lower the CPU time available.