This is because I faced a problem with I2C communication:
- When I communicating my firmware based on Atmel’s AVR302 application note source code, it works as expected;
- When I poll LM75A I2C thermometer it also working fine, but after I read value from it strange side effect appears: my firmware stops responding with address acknowledge when I trying to address it;
- After few (rather random) polls to LM75A my firmware are able to process commands until thermometer part is polled again.
There are many wait loops in firmware source code originated from app note like following:
sbis PINB,PINB2 ; wait for SCL high rjmp whi_dac wlo_dac:
sbic PINB,PINB2 ; wait for SCL low rjmp wlo_dac
It seems to me that because of incorrect handling of a bus states firmware hangs on one of these loops.
I ordered logic analyzer to examine bus traffic but because it seems that the package delayed somewhere due to Chinese New Year I want to try today one approach that come to my mind during last week how to debug firmware inside ATTiny13 without hawing hardware debugger. Idea is pretty simple:
- ATTiny13 has 8 pins;
- 3 is pre-occupied (RESET, VCC, GND);
- On 2 pins (PB2(T0) as SCL and PB1(INT0) as SDA) sits I2C bus;
- Thus 3 pins (PB0, PB3, PB4) are free and could be used for debug purposes.
Idea is to use LEDs connected to free 3 pins as indicators of key points in source code. 23 gives us 8 possible combinations. All that I need is to set PB0, PB3, PB4 to HIGH/LOW state according to key point number in binary format.