Problem with 16 bit AVR register (temp register oddness)

I need to use the 16 bit counter/timer (AT90S2313-10) and fully understand the order of reads and writes to ensure atomic updates using the temp register (App Note AVR072).

My problem is that I only want to change the lower 8 bits of the compare register. Expecting the temp register to be written to the high byte when I set the low byte I attempt to get the current high byte into the temp register first.

in R1, OCR1AL ; Get current low byte just to get high byte->temp ldi R1, newValue ; Load new low byte out OCR1AL, R1 ; set new low byte and temp -> high byte

Well it works perfectly. Apparently.

The problem is that try as I might I could not get it to fail when I expected it to leading me to question how the temp register works.

App Note AVR072 cautions that interrupt code that reads or writes a low byte of the same timer between the low and high byte reads could wreck the temp register. This is because there is (they claim) only one temp register shared by all the 16 registers of the timer.

I can't get that problem to happen.

in R1, OCR1AL ; Get low byte. High byte -> temp register in R16, TCNT1L ; read or write here to change 'temp' register in R2, OCR1AH ; get high byte from temp register

R2 ends up holding the expected value. The problem is that the middle read should have wrecked that temp register, but it didn't.

Am I missing something? Did they make a change that provides a unique temp register for each 16 bit register?

I don't want to trust my scheme to only change the lower byte (which saves an instruction and a cycle) if it's likely to be fragile.

Any advice would be gladly received

Thanks!

---- Andy snipped-for-privacy@wcoastsidew.net // Drop all three w's

Reply to
Andy Carol
Loading thread data ...

But Atmel do not guarantee that all AVR MCUs behave like that. A good program should not count on unspecified features ...

If your interrupt handlers do 16Bit accesses you should do a 'cli' before the 16Bit accesses in the main program to be save.

Micha

Reply to
Michael Baeuerle

wow, watch out for radiation

updates using

Reply to
Rein Wiehler

If he writes it carefully [and accesses the registers only as the manufacturer specifies], his code won't decay.

-----

formatting link

Reply to
Ben Bradley

But it still might Cesium and lock up at which point the watchdog reset feature should come in handy.

-Brian

--
Brian Dean, bsd@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
http://www.bdmicro.com/
Reply to
Brian Dean

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.