I filed a bug for this but mention it here in case anyone else is tearing their hair out. Simple demo case is New Project - I'm using an avr-gcc C executable - which creates just:
#include <avr/io.h>
int main(void)
{
while (1)
{
}
}Target an ATtiny214 to run on the simulator, and set the toolchain for no optimisation. Position the cursor on, say, the while's closing brace and run the debugger to that point. Open a Memory window on data INTERNAL_SRAM to show at least the stack (from 0x3FFF downwards - see the datasheet p17). If your Studio behaves like mine, no matter what you try to refresh that Memory window you'll get something like this:
If you stop debugging and make no other change except to target a different processor, it'll work - kind of. The easiest is another from the same device family - an ATtiny414 or ATtiny814 - because they have the same RAMEND as the ATtiny214: 0x3FFFF The same thing will give you this Memory window instead:
which is exactly as you'd expect. Check the disassembly above and you'll see Y being used to initialise the SP, so it still has that value upon entering main(). The return address is pushed first (0x0021 at 0x3FFFE) then Y (0x3FFF at 0x3FFC).
If anybody knows why it doesn't happen for the ATtiny214, and how to fix it, then I'll be very grateful. Meanwhile you can still debug code for the ATtiny214 on the simulator, you just can't see what the SRAM's doing. While I wait for hardware I'm targeting the ATtiny414 instead: its RAMEND is the same, and the debugger and simulator work with it.
A similar - and I suspect related - problem crops up with other chips: their SRAM displays work under simulation, but randomly display the correct contents at incorrect addresses. For example, I tried exactly the above, targeting an ATtiny24A and an ATtiny2313; sometimes their SRAM would appear at addresses that were multiples of a page higher than they actually are - as if RAMEND were 0x03E0 instead of 0x00E0, for example. Restarting the debugger was often enough to fix it but I haven't found a reliable method. Again, tips welcome (even if they're only, "Noob, RTFM: we've known how to fix this for years" :-D ).
