Why two NOPs are used after "SSRF 16"?

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

I've seen that people append two NOPs after setting the GM mask in the SR on the AVR32-UC3.

SSRF  SR_GM_OFFSET
NOP
NOP
...

Why?

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

Probably to clear the instruction pipeline to make sure interrupts are really disabled.

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

Absolutely, pipeline seems implicated here, but I still don't quite understand whether the two NOPs are absolutely necessary and if it is wrong not to have them.

I mean, the ASF built-in function for disabling interrupts cpu_irq_disable() does NOT generate the two NOPs, as I verified by looking at the disassembly window.

So, which way is it. Shall I use the two NOPs just for good measure, because "that is how it's done"?

How do you guys disable interrupts?

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

Two NOPs were needed on early versions of the UC3 devices due to a hardware bug. This has been fixed in newer hardware revisions.

Letting the smoke out since 1978

 

 

 

 

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

digitalDan wrote:
Two NOPs were needed on early versions of the UC3 devices due to a hardware bug. This has been fixed in newer hardware revisions.

Could this relate to the probable processor bug I found?
https://www.avrfreaks.net/index.p...

The faulty situation here apparently usually comes after three or four nops from the interrupt disable though. The exact specification of the part we use is (as printed on the UC's surface):
32UC3C1512C
-U
1122E PH
D5GH1.1JJ

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

You should contact Atmel about that, they know exactly what those numbers mean.

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

jayjay1974 wrote:
You should contact Atmel about that, they know exactly what those numbers mean.

I did. Almost two weeks ago... (See the topic with the bug, I posted an update there)

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

dev.null wrote:
Could this relate to the probable processor bug I found?
https://www.avrfreaks.net/index.p...

I would guess no. I believe this bug was fixed in the UC3A and the UC3B well before the UC3C came out.

Letting the smoke out since 1978