Studio 6.2 Appears to have wrong addresses for Timer1 regs on Attiny24A/Simulator

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

I'm debugging an attiny24a using the simulator.   I've made sure the device is set to attiny2a4 and that the compiler is getting invoked with the -mmcu=attiny24a symbolic constant definition

 

I quickly noticed that after a command like:

 

OCR1A = 10;

 

The GUI showed OCR1A still set to 0x0.  Then I noticed the addresses for the Timer1 registers as reported by the GUI aren't correct:

 

 

 

The generated assembly code looks correct.

 

Is this a know issue with Atmel 6.2 when using tool simulator on an attiny24A?  Or, is there something else going on?

 

Thanks!

 

Last Edited: Wed. Jan 25, 2017 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe it's relevant--the project started out as device ATTiny25.   I changed to ATTiny24A to get more I/O so I could drive two PWM outputs and cut the # of processors/cards in the system in 1/2.

 

Also, there are multiple projects in the solution.   I just changed the one I'm debugging to ATTiny24a.  The rest are still at Attiny25. 

 

Maybe Studio has an issue keeping the device in sync with the current project?

 

I can test that by going ahead and changing all the projects to device ATtiny24A.

 

 

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

davethomaspilot wrote:
I quickly noticed that after a command like: OCR1A = 10; The GUI showed OCR1A still set to 0x0.

Datasheet wrote:
The OCR1x Register is double buffered when using any of the twelve Pulse Width Modulation

(PWM) modes. For the Normal and Clear Timer on Compare (CTC) modes of operation, the

double buffering is disabled. The double buffering synchronizes the update of the OCR1x Com-

pare Register to either TOP or BOTTOM of

the counting sequence. The synchronization

prevents the occurrence of odd-length, non-symmetrical PWM pulses, thereby making the out-

put glitch-free.

 

davethomaspilot wrote:
Then I noticed the addresses for the Timer1 registers as reported by the GUI aren't correct
The addresses seem to be correct to me.

Stefan Ernst

Last Edited: Thu. Jan 26, 2017 - 01:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm aware of the double buffering on the OCR1x.  Why is that relevant?

 

Why do you say the addresses seem correct?   They OCR1A should be at 0x2b and 0x2A.  From the Attiny 24/44/84 spec

 

 

 

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

Ah, I now see the update doesn't occur until the counter reaches TOP/Bottom.

 

Still confused about the address though.

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

davethomaspilot wrote:
They OCR1A should be at 0x2b and 0x2A. From the Attiny 24/44/84 spec
Look again at that picture. Those 3 (well almost 3 if TCNT1L were not chopped in half) registers have TWO addresses shown for each. TCNT1L is both 0x2C and 0x4C. OCR1AH is both 0x2B and 0x4B. OCR1AL is both 0x2A and 0x4A.

 

In the datasheet for 24/44/84 I think you need to understand some more about this diagram:

 

 

That shows that the 64 IO registers (the Special Function Registers - SFRs) live in the RAM map between 0x20 to 0x5F. If you access them using LD/ST/LDS/STS and variants you will use their "RAM" locations so for TCNT1L that would be 0x4C and for OCR1AL it would be 0x4B and so on.

 

HOWEVER the AVR can also access low memory addresses using IN/OUT (and for bits in some part of the range CBI/SBI) but the IN/OUT opcodes only have 6 bits available to identify the location, they also aren't used for the first 0x20 bytes (0x00..0x1F) of "RAM" as that area is where the AVR registers are located (and there's other ways to quickly access those like LDI). So Atmel chose to map the IN/OUT to work on the 0x40 bytes from RAM location 0x20..0x5F where the SFRs are all located (on small AVRs). But it would be a waste to encode that 0x20 in the opcode so it addresses them with a 0x20 offset so an IN from 0x1C is actually an access to RAM location 0x3C and so on. An OUT to 0x2A is a write to "RAM" location 0x4A.

 

In C if you use:

OCR1AL = 0x55;

the compiler has two choices it can either use:

LDI R24, 0x55
STS 0x004A, R24

or it can use:

LDI R24, 0x55
OUT 0x2A, R24

The simulatror/debugger meanwhile just shows you everything in "RAM" so will show that with a 0x004A address. But if you single step:

OUT 0x2A, R24

you will see the update occurring at RAM location 0x004A

 

The C compiler will uses STS (actually something even worse using Z addressing!) if you have the optimiser switched off. With optimisation switched on it will spot that 0x004A is in range of an OUT and will convert this to an OUT 0x2A instead.

Last Edited: Thu. Jan 26, 2017 - 12:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for taking the time to explain that so well.