Go Down

Topic: How to shoot yourself into the foot... (Read 429 times) previous topic - next topic

udoklein

Currently I am messing a lot with inline assembler. Especially I refer to ports and registers like so:

Code: [Select]

           :      [gtccr]      "M" (_SFR_IO_ADDR (GTCCR)),
                 [tcnt0]      "M" (_SFR_IO_ADDR (TCNT0)),
                 [gtccr_mask] "M" ((1 << TSM) | (1 << PSRSYNC)),
                 [eimsk]      "M" (_SFR_MEM_ADDR(EIMSK))


Now instead of using OUT to set GTCCR is used STS to "access it". This however outputs into PINB. Now the interesting thing is what happens. Obviously PINB is supposed to be read and not to be written. One could assume that the effect is that the command is just ignored. But this is not the case. What happens is that it seems to be ignored but some seconds later the processor starts to behave strange.

Cost me about 2 hours debugging ...

Any comments why this bites back only with some delay? This is something I would not have expected at all.
Check out my experiments http://blog.blinkenlight.net

retrolefty

Quote
Obviously PINB is supposed to be read and not to be written.


If you write a bit(s) to PINB then the corresponding bit(s) in PORTB  will toggle from their previous value. This feature was added to the newer Atmel AVR chips. The datasheet covers the toggle feature.

Lefty

udoklein

Aha, so since the pins were configured as inputs this supposedly toggled the pullups. Hence the pins started floating. I infer my program did not crash but just block due to the unexpected amount of input. And it explains why it took some time. Obviously the charge needs some time to drain till the pins start floating.

At least now I understand what happens.

Thanks a lot.

Udo
Check out my experiments http://blog.blinkenlight.net

Go Up