The problem is that my logic analyzer is not able to detect this
signal most of the time, but I do see a signal edge only immediately
after the transceiver has been put into PLL_ON. The rest of the code
works, and I can see the effects of adjusting my overflow interrupt
frequency (meaning adjusting the prescaler). The interrupt is
responsible for setting a flag that allows the FIFO to be sent, thus
the signal edge will always be right near where I transition into
PLL_ON.
through many tests, I conclude that my timer4 overflow interrupt is
firing, it is indeed firing because changing the prescaler changes my
timeouts, which I am able to observe, so I am absolutely 100% sure
that the interrupt is firing. All the other interrupts are firing as
well. The application works as expected.
here's the weird part, if I compile my code with a single
"delay(100);", then magically, the pin toggles!
What's causing this?
Can you post the problematic code, both with and without the fix? The
only thing that I can think of is that the optimizer is doing
something odd -- have you tried disassembling it with AVR Studio?
-p
--
Pierce Nichols
Principal Engineer
Logos Electromechanical, LLC
The disassembly shows nothing wrong. In both cases, I clearly see the
instructions to toggle that pin inside the __vector_45, which is
indeed the timer4 overflow interrupt. The disassembly looks mostly
identical except for very minor differences, and some differences in
how some functions are ordered.
Another funny fact, delay(100) will make the pin toggle but delay(1)
or delay(10) will not.
I used my DSO Quad and it appears that the logic analyzer is working
correctly, I do not see any square waves on the oscilloscope as
expected.
With the oscilloscope, I've ruled out the protection circuitry messing
up voltages. I think this leaves a silicon bug or a compiler bug, the
disassembly makes me think it might be a silicon bug.
I'm actually not going to pursue this issue any further myself, I
figure I'll throw this behaviour out there and maybe somebody else
have already encountered it.
The code is too complicated to share easily right now. It involves an
Arduino core, a library, and a sketch. I'll share it only if anybody
is actually interested in trying to replicate and solving this
problem.
-Frank
Does it work the same way if you use a different pin? If it's a
silicon bug, it would be good to report it to Atmel.
-p