Newbie problems with ATtiny13 interrupts/LED

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

Hello AVRFreaks!

 

After my first step into the world of microcontrollers and embedded systems, it's time for me to meet the AVRFreaks community.

That feeling of massive joy after successfully blinking a LED on my first MCU is now being exceeded by the feeling of stiff neck and headace.

 

I have two LEDs connected to a ATtiny13a microcontroller and I am trying to make a LED fade up/down a little bit, by changing its PWM duty cycle (long term goal).

For beginning I only wanted to have the green LED driven by PWM (and changing its brightness/dutyCycle) and the blue LED constantly turned ON (current problem / short term goal).

Green LED is connected to PB0/OC0A, Blue LED is connected to PB2.

 

By commenting out code line-by-line and recompiling it, I noticed that if I delete or comment out the ISR block, it works okay. If I try to add ISR

none of the LEDs turn on. Am I missing something obvious?

 

#define F_CPU 1200000UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>


int main(void)
{
  DDRB = 0xFF;                // Set portB as an OUTPUT
  PORTB |= (1 << PB2);        // Turn the blue LED ON

  TIMSK0 = (1 << TOIE0);      // Enable Timer overflow interrupt

  TCCR0A = (1 << WGM00);      // PWM phase correct mode
  TCCR0A |= (1 << COM0A1);    // Output PWM on pin OC0A/PB0 = green LED
  OCR0A = 128;

  TCCR0B = (1 << CS00);       // Start timer, no clock prescaling
  sei();


  while(1)
  {}
}

// Deleting this ISR, makes the LEDs glow fine.
ISR(TIM0_OVF_vect)
{

}

 

I am using Atmel ATtiny13A-PU, USBtinyISP programmer (by Adafruit), compiling with makefile (avr-gcc) and uploading with AVRdude on Ubuntu 16.04.

 

Here is the makefile (output looks okay, other programs worked fine):

 

NAME=led_glow
MCU=ATtiny13

CC=avr-gcc
CFLAGS=-Os -mmcu=attiny13a

#   avr-gcc -g -Os -mmcu=attiny13a -c led_blink.c
#   avr-gcc -g -mmcu=attiny13a -o led_blink.elf led_blink.o
#   avr-objcopy -j .text -j .data -O ihex led_blink.elf led_blink.hex

################################################################################

${NAME}.hex: ${NAME}.elf
	avr-objcopy -j .text -j .data -O ihex $< $@

${NAME}.elf: ${NAME}.o
	${CC} -o $@ $^

install: ${NAME}.hex
	avrdude -c usbtiny -p ${MCU} -U flash:w:$<

clean:
	rm -f ${NAME}.elf ${NAME}.hex ${NAME}.o

 

And the setup:

protoboard circuit

 

Also, I know I should use decoupling capacitors (even tho I don't know much about decoupling really), but at the moment I don't have them. Also - is this really extremely important in an application as simple as this one?
It's my first time posting in this forum, please let me know If I did anything wrong (I searched the forums for similar problems unsuccessfully).

Thanks alot for your time and help!
Jure

Attachment(s): 

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

It would seem that the green LED is on at approx half brilliance, because it is running at PWM 50% (value: 128 on an 8-bit timer).   The other LED is on because its cathode goes to ground (0v) and its anode is connected to an output port that defaults to logic high (Vcc, +5V usually).   Verify this by setting OCR0A to 30, which would make the green LED dimly on.  Also try turning the blue off with: PortB &= ~(1<<PB2);   

 

The ISR for overflow on the Timer is active and running.  But on each overflow, the code sets up and goes to the interrupt service routine and does nothing but return back to the main code because there is no code between the ISR's braces.

 

If your power supply is noisy with lots of voltage spikes, then one of those spikes might cause the AVR to operate below its minimum operating voltage.  Or, the power may dip below min when the LED switches on, if the power source is weak.  A decoupling capacitor acts as a voltage shock absorber.  Often there are two of them, a 10uF and a 100 nF (or 0.1uF).  The spike is not 'coupled' from the power source to the AVR.

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

Set PB0 to be an output.
Try a timer-prescaler of 1024 and see if the green LED flickers.

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

Thank you both for your answers!

This morning I woke up and tried to upload the same code to the microcontroller- and the avrdude failed ("could not find USBtiny device (0x1781/0xc9f)").

I am 100% sure I didn't touch anything and that the same setup worked yesterday. I guess there must be something wrong with my toolchain, or maybe

programmer or computer or the circuit. I also tried another microcontroller and avrdude fails to find it as well.

 

I noticed this strange behaviour couple of times now, and I believe that having ISR routine defined in code or not, should not affect the LEDs (since the ISR is empty!)

and specially shouldn't affect the blue LED (which is on a pin that has no connection with PWM/interrupts or anything)...

I will try to re-connect everything and upload some other programs (even simpler) to see what is going on. I can then try setting a timer prescaler.
Also, afaik PB0 is already set as an output, since I've set whole portB to an output? DDRB = 0xFF?

thanks

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

jurc192 wrote:
I am 100% sure I didn't touch anything and that the same setup worked yesterday. I guess there must be something wrong with my toolchain, or maybe programmer or computer or the circuit.
Software rarely "changes" over night but programmer wiring often does (in my case the cat walks on it!) so I wouldn't jump to the conclusion that it's the toolchain etc.

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

Breadboards suck!  Its not unusual for them to have bad/loose connections that develop over night, or any other time.

Re-check, re-make your connections and try again.   In the mean time pick up a hand full of 100nf caps to use as bypass caps.

Place them on all chips across vcc and gnd using short leads, life will be much better if you do. (yes even on simple circuits)

 

Jim

 

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

ki0bk wrote:
Breadboards suck!  Its not unusual for them to have bad/loose connections that develop over night, or any other time....
I guess some breadboards suck. I have a 41 year old breadboard, here. The nylon blocks have turned an off-white and the contacts doubtless have a patina of some sort of nickel-silver oxide. Perhaps the contact resistances are higher than they used to be – I recently measured a few, which were all under half an ohm – but it has never given me trouble.

- John

Last Edited: Wed. Feb 7, 2018 - 05:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Okay, then I'll try soldering things together - just to see if that's the problem. I re-connected everything and I am still getting weird things going on.

I don't even feel it would makes sense to explain all of them here. One time I upload the code and it works, then it doesn't.

 

Is it possible that only "one part" of the microcontroller is damaged?
However, I just wanted a confirmation that my code is not missing anything obvious. I guess the problem lies somewhere else.

 

BTW how do you guys prototype, if not with protoboard?

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

jurc192 wrote:
One time I upload the code and it works, then it doesn't.

 

That is partly due to your haywire wiring, another recent thread had a similar problem that went away when the BB layout was re-done using neater (shorter) wires.  Neatness does count! smiley

 

As for my prototyping, I will BB a small portion of a project, a new sensor for example, but use proven past systems to test with, once its working it gets a layout on a PCB.  I also use a lot of Arduino nano's and pro-micros, no need to BB a micro anymore, these are cheaper and work out of the box.

 

Jim

 

Example, I'm working on a project at home where I use a pro-micro for the brains, it dropped onto a pcb I had made, to prototype the product, it will take one more board spin to be ready for production.

In another project here at work, I BB'd an I2C LED driver using a nano to test it, once it was working, I handed the BB to our Linux guy to write the driver for it, it has a pair of jumpers to our production unit, a new PCB was ordered and is on its way from china, will be here later this week.

Edit: spelling

Last Edited: Wed. Feb 7, 2018 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Link to other thread where neatness helped:   http://www.avrfreaks.net/forum/s...

 

 

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

After few hours of soldering my own little development board, I connected two LEDs and blinked one of them (no interrupts, delay+toggling). Then it stopped (after ~1min). What a shitty feeling.

Then I noticed, that the circuit won't work anymore if I disconnect the programmer. After reading this I noticed I didn't have my 10k pullup resistor

on the ~RESET pin. For some stupid reason I thought the programmer can handle this, but didn't think about how it's gonna work without a programmer attached.

 

Also, if you connect the programmer to the circuit but leave it unconnected on the "PC" side -> the circuit won't work. You have to either disconnect the

programmer from the MCU or connect it completely, to PC also. Does this make sense, or is it something wrong?

 

I already thought I solved the problem, but after trying to upload the same code with ISR, the same problem appeared again.

Lessons learned: don't forget the pullup resistor, buy a proper development board and get those decoupling capacitors.

 

I guess I shouldn't bother you all until I do this :)

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

jurc192 wrote:
For some stupid reason I thought the programmer can handle this, but didn't think about how it's gonna work without a programmer attached.

/RESET has an internal pullup.  Adding an external pullup to the weak ihnternal one gives more robust operation in "field" operation.  (also many prior discussions about capacitor also, and/or diode)

 

In a clean environment such as desktop, with clean connections, both ISP and normal operation are fine without external pullup.  If that situation caused you pain, then you did not have clean connections.

jurc192 wrote:
You have to either disconnect the programmer from the MCU or connect it completely, to PC also. Does this make sense, or is it something wrong?

That entirely depends on your programmer, and what effect it has on connected signal lines when not powered.  What effect it has would certainly depend on the application that is trying to run, also.  (really no different than having chaff sprinked across the connections on any electronic device)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.