BREQ Instruction Bug

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

Hi there,
I have a Attiny84A at hand which I run at 1MHZ / 5V.

 

I experience a malfunction of the BREQ instruction.

Here's my code:

start:
     SBI DDRB,2 ; DDRB |= 1 << 2; 	Set pin as output (a LED is connected)
     CBI PORTB,2 ; PORTB &= ~(1 << 2)   Clear Pin
comp:
     SEZ    ; Set Zero Flag
     BREQ comp ; Jump if zero flag set
     SBI PORTB,2 ;  LINE SHOUDLD NEVER BE REACHED.     PORTB |= 1 << 2  Set Pin On
     RJMP comp

 

When I power cycle the MCU a few times at some point the Pin wil be turned to High, altough it never should!

 

Do you have any idea what could be the issue here?

Or did you experience something similar?

 

Thanks in advance.
Regards

 

Timo

 

 

EDIT: Replaced IO register Numbers with PORTB/DDRB constants

 

 

 

Last Edited: Thu. May 9, 2019 - 08:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AVR is a two-phase "pipeline" RISC processor.  It is possible that the first phase of the SEZ has completed [analyze the instruction] when the BREQ starts its first phase.  Possibly the zero flag has not been set when the BREQ examines that flag.   Setting the zero flag possibly happens at the second phase of the SEZ.

 

Try putting a NOP between any instruction that changes a flag and an instruction that acts on the state of that flag, in this case between the SEZ and the BREQ.  NOP (no operation) will not change any flags.

Last Edited: Thu. May 9, 2019 - 08:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post the full program, maybe something else is screwy and the code just goes haywire. And it's not nice to replace the port name with a number.

 

Also how is the LED connected?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I tried inserting NOPS between every single instruction. Doesn't change anything...

 

What I noticed though:

When I power the MCU with only 3.3V it happens very rarely (~ 1 of 100 tries).

With 5V it happens in around 1 of 5 tries.

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

@js

this is the full programm.

 

Sorry for the numbers. I normally write C code.

This is just the relevant part that reproduces the problem fully (when flashed as posted without any other code).

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

I normally write C code.

And you usually use labels and not magic numbers, right? Also do you have any electronics experience? ie how is the board wired? Bypass caps in place? Resistor in series with led? Reset pin not getting any noise?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

How do you power cycle ?

 

Do yo have BOD enabled ?

 

For me it looks like a HW reset problem, so it can run at to low voltage.

 

 

Add:

And how is reset connected ?

 

Last Edited: Thu. May 9, 2019 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Sorry for the missing labels. I just copied it of my disassembly without thinking twice. Sorry. for that. I've edited the startpost now.

 

The led is connected directly with the Anode to PB2

Reset is wired to VCC.

VCC and GND are connected directly.

Nothing else is connected.

 

I'm an electronics engineer. But I don't have that much knowledge in the prototyping field and with attiny's I'm a newbie.

 

Thanks for the good questions, to rule out errors :)

 

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

I power-cycle by removing and re-inserting a wire on my prototying area. I agree, this could cause some jitter (on vcc+reset equally).  But still it should not skip the BREQ instruction right?

I  enabled brown out detector at 2.9V. So it should not be a low-voltage issue.

 

 

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

How big is the serial resistor on the LED? , sounds like it's not there ;)

 

 

Add:

And I expect that you have a 100nF local capacitor between GND and Vcc ;) 

Last Edited: Thu. May 9, 2019 - 09:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yap. There's none.

Driving the pin current to the limit, once the led is enabled.... (Which should never happen so.....)

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

There's no 100nF local cap either.  I was hoping it would work without, since I had no cap lying around.

 

But I will check tomorrow. With a proper buffering via local cap. And with a proper reset circuit.

 

And then report back.

 

Thanks so far.

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

Perhaps the pull up resistor is undefined, try to disable it when you init the port.

 

 

does the LED lit bright? (perhaps it just the port pullup )

 

add:

Forget it this is a push pull IO

Last Edited: Thu. May 9, 2019 - 09:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Methinks 'tis definitely a hardware problem.

Try replacing the AVR.

Try adding a couple more LEDs on different pins,

one that should be always on (pin high),

the other always off (pin low).

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

I give up on some threads, sorry.surprise

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Instead of pulling the power, tie a switch or wire jumper to the reset line to restart the program....see what happens then.

 

maybe the program is latched up ...not actually running.

 

Add another sbi & cbi into your loop (say for pin3) ...put that on the scope...you should see a square wave if the prog is running, whenever you see your LED problem...bet you'll see the led light & no squarewave (AVR locked up).

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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


 

I give up on some threads, sorry.surprise

 

Some threads last forever

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Driving the pin current to the limit, once the led is enabled.... (Which should never happen so.....)

Yes you do for 1 us!

 

Swap the order of the two first instructions. 

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

sparrow2 wrote:

Driving the pin current to the limit, once the led is enabled.... (Which should never happen so.....)

Yes you do for 1 us!

 

Swap the order of the two first instructions. 

that depends. reset state of the IO lines is input without pull-up (DDR & PORT register are 0) So it should go from input no pull-up to output low and then make sure it is low....

But that depends on what was the state of the line was of coarse prior to this short program starting.

 

 

 

 

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

How are your fuses set?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

I can no longer reproduce the issue. 

I haven't changed anything on the wiring or program. The only thing that might have changed, is the load on my power-supply.  (I added other circuits on the same prototyping area, that are not connected to the circuit in question except via VCC/GND)

This looks to me like it was indeed a problem with the supply voltage. 

 

Thank you for all your inputs and ideas. I really appreciate the fast and helpful responses.