Re: [avr-gcc-list] AT90CAN128 silicon bug in conjunction w/ external RAM

[Marek Michalkiewicz]

On Sat, Apr 16, 2005 at 09:45:20AM +1000, Henrik Maier wrote:

> Atmel's fix/work around is not to place SP into XRAM. As for most
> software projects this is a plausible workaround, it is not suitable
> with some multi-threaded RTOS which place SP in dynamically allocated
> heap memory.

Still, another good reason for placing the stack in internal SRAM is
faster access (one less clock cycle).  Better yet, if each task has
a stack area which fits entirely within a 256-byte page (so that SPH
doesn't change), the -mtiny-stack optimization is possible.

> Reading Atmel's explanation, I am wondering if another work around would
> be not to use IN/OUT instructions at all.
> 
> Therefore I am asking the questions, is there a compiler switch or a
> simple patch for avr-gcc to make it not use IN/OUT instructions and to
> use LD/ST instructions only instead?

It should be fairly easy to add such a switch to avr-gcc.  But, I'd
suggest to ask Atmel to be sure:
 - is LDS/STS really not affected by this bug?
 - do other I/O instructions (CBI, SBI, SBIC, SBIS) work correctly?
 - is this for AT90CAN128 only, or does it affect any other devices?
   (such as ATmega128)

BTW, it's not the first bug of this kind - ATmega161 had this errata:

<quote>
Interrupt Return Fails when Stack Pointer Addresses the External Memory
When Stack Pointer addresses external memory (SPH:SPL > $45F), returning
from interrupt will fail. The program counter will be updated with a wrong
value and thus the program flow will be corrupted.
Problem Fix/Workaround
Address the stack pointer to internal SRAM or disable interrupts while Stack
Pointer addresses external memory.
</quote>

Thanks,
Marek