Unexpected behavior of read-modify-write instructions right after using OUTCLR,OUTSET,OUTTGL PORT access

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

Accessing the same port using regular PORT and consequently with VPORT gives unexpected behavior.

 

Consider these two code examples:

First:

ldi r24,1

out PORTA_OUTSET,r24

sbi VPORTA_OUT,1

//after this, bits 0 and 1 of PORTA should be set, but bit 0 is not set

 

Second:

ldi r24,1

out PORTA_OUTSET,r24

nop

sbi VPORTA_OUT,1

//this works as expected

 

The problem is that read-modify-write of the VPORTA_OUT is done on PORTA_OUT state, that is obsolete an the moment. This issue has something to do with propagation delay of PORT operations. SBI instruction reads the PORTA_OUT state before the previous instruction is fully propagated through the flip-flops and the PORTA_OUT value is updated.

 

When debugged step by step, the PORT has enough time to update and the error doesn't come up.

Conclusion: Using VPORT and read-modify-write instruction should not be used right after PORT write through STS.

Last Edited: Wed. Nov 25, 2020 - 10:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which chip(s)?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

JohnCZ wrote:

Consider these two code examples:

First:

ldi r24,1
out PORTA_OUTSET,r24  // I would expect this line to give an error
sbi VPORTA_OUT,1

Correct me if I'm wrong but I don't think any XMEGA type AVR has PORTA located in the IN/OUT memory area.

The whole VPORT thing exists to provide that type of access.

 

Last Edited: Wed. Nov 25, 2020 - 10:58 AM