AVR Freaks

It appears the compare flag was being correctly set by the compare value match.

It was an incorrect thought and after three late nights i just started thinking anything is possible.

Using an Atmel Ice for the first time for on-chip debugging instead of only the simulator.

Things move alot faster.

One problem i found last night thanks to the ICE is this syntax error:

PORTB.OUTCLR |= PIN1_bm; // Instead of PORTB.OUTCLR = PIN1_bm;

*|= toggled all the ports that were set as outputs.

My next step is alot of break points for where im getting stuck.

Thanks everyone for all your input.

Hey Kabasan, With my problem I have found  a compiler optimization bug.

I have TCA0 compare channels: CMP0 set to 256 and CMP1 set to 39. TCA0 is clocked at 7812.5 hz, nice and slow.

When the chip is booted up it sets up the chip including initial compare values, then enters sleep mode.

A pin change interrupt wakes out of the power down sleep mode.

Once my sleep_cycle function exits:

The code jumps immediately to TCA0.SINGLE.INTFLAGS = TCA_SINGLE_CMP1_bm;/*writing 1 to flag clears avr flags*/

In this if statement conditional in my main loop code:

*EDIT had to swap THIRTY2_MS with FIVE_MS, still is the same code jump problem.

if(TCA0.SINGLE.INTFLAGS & TCA_SINGLE_CMP1_bm){//5ms compare match
         TCA0.SINGLE.CMP1 += FIVE_MS;// resets/adds 5ms to counter compare
         TCA0.SINGLE.INTFLAGS = TCA_SINGLE_CMP1_bm;/*writing 1 to flag clears avr flags*/
         buttonsPressed();
                   }

It jumps to it without even checking the conditional or starting anywhere near that code and the compare match never occurs within hardware the first time around, it just counts past

39 willie nilly and never sets the flag the first time around.

This is with optimization set for size (-Os)

When i turn optimizations off the code does not jump into that if_statement and the COMP1 match triggers the compare flag when the counter reaches 39-40.

Super weird!

I have set up debugging for no optimizations for more readable debugging.

Although  what i observed was very odd, i have now discovered another/ the bug in my code.

There is a while loop that is pushing time/clocks well past my  "every 5ms" CMP1 compare match being flagged.

So CMP1 flag is being checked via the if_statement well after (>39 TCA0 clocks in this case)the Counter value matched the compare value, so when CMP1 += FIVE_MS;

: It is updating a Compare match value that is lower than the Counter value (after a certain part of my code), which is also a 16bit counter that has to count back around to compare!

Its about 8seconds to over-flow and check if the CMP1 flag was set.

Found that bug, gonna kill it with fire.

I swapped code from another chip to this one, along with learning Atmega > Xmega . I am comparing the old chips code to this one and its baffling why i did not have this problem before.

Thanks for your help.