ATtiny214 debugger Memory SRAM doesn't update?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


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 ).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your issue with the tiny214 is most certainly a bug in the simulator. It's the same model as the tiny41x, so probably a "wire crossing" when halving the SRAM. As you say it simulates fine, it's just the display of the SRAM that's missing. A bit important feature though...

 

The other issues you mention, with ATtiny24A and ATtiny2313 sounds strange. No idea what that can be.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks! That makes sense - good to think it mightn't be something dumb I've done ;-)   Re. the ATtiny24A and ATtiny2313: I only happened to try those because I had the datasheets to hand, so knew where their stack contents should appear. It's possible the same problem applies to other chips as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it was consistent, then yes it could be the same problem. But you say it "randomly display the correct contents at incorrect addresses".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should describe that second issue - with the address offset - less, er, randomly ;-)

 

It's consistent in that the errors I've seen have always caused an offset of some multiple of 256 bytes. What I'd find always is that the entire SRAM would be displayed either in its correct address range, or displaced upwards by a page, or two, or even three or four. (Above the lowest SRAM image the whole block ghosts repeatedly of course, but that's to be expected and is probably an accurate simulation of the chip - I don't think it's a problem.)

 

What's random is the particular displacement: sometimes I'd reopen Memory and it'd be four pages off; others it'd be correct; or another time it'd be one page too high - I haven't seen any pattern to it.

 

Simplistically, it smacks of only the low byte of a pointer being set and the high byte accidentally being used with some previous value. Tables growing to where they spill into a higher page perhaps, breaking an older assumption that their high address byte didn't need adjusting?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

The issue with ATtiny214 is now resolved, and the fix will go public with the next ATtiny_DFP update. Meanwhile you can replace the simulator model in your current DFP with the one attached (default location: C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\<dfp-version>\simulator\win32).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lloydb wrote:
Target an ATtiny214 to run on the simulator, and set the toolchain for no optimisation.

You should use -Og for debugging! -O0 is for compiler writers use only, makes very bloated code.

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or people that want to see how a compiler "think" before it start to optimize.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi @je_ruud

 

That's great. Installed the update, and a quick check shows the SRAM display for the ATtiny214 is now showing more than 0x00 :-)  Thanks for the quick fix.

 

Re. the page-offset problem which affects other chips as well: will wait for a fix in due course.

 

I've updated the ticket at Microchip support accordingly: 00675459