Need help! LED does funny stuff on simple command, not sure why [attiny816]

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

Hi,

 

I have a board using attiny816 (not using any xplained mini board)

 

I have a  blue LED connected with PB5 of the tiny816. Was working fine yesterday afternoon but this morning, I saw the blue LED turning on when I just do the following simple code. (I was just doing a simple LED blink to see what happened, but I currently removed the toggling part at this time).

 

But when I have the blinking part added, the LED blinking seems to operate normal, making me believe that the PB5  on the tiny816 is working fine. I also have an ambient light sensor on the same board I'm using and my ambient light sensor code appears to turn on and off the blue LED at the right time and LED appears to be ok as expected but was trying to figure out why sometimes I see LED turned on when I ONLY have the instruction to set port B pin 5 as output and nothing else in other code.

 

 

What may be going on? I'm confused...

 

 

I am only setting Port B Pin 5 as an output, and that's all. I've done that many times on previous stuff without any issue, but this is the first time I've encountered this issue.

 

 

 

#include <avr/io.h>

int main(void)
{
    // set pin 5 as output

    PORTB.DIRSET = PIN5_bm;
}
Last Edited: Thu. Mar 15, 2018 - 04:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have proper decoupling caps on your board?

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

I don't understand what the problem is.  If the LED is connected active-low, then indeed that would be expected operation.  You have not given us a schematic.

 

BTW, in your shown program, what do you expect to happen after the .DIRSET line?  I guess we can infer GCC, and then infer that most versions have a catch-loop after you run off the end of main()?

 

No warnings?  About lack of return value or otherwise?

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.

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

What value resistor do you have in series with the blue LED and what is voltage level is VCC?

 

Jim

 

 

FF = PI > S.E.T

 

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

From one test (I'll try more later to double verify what I'm seeing). Yes the led on PB5 is active low. Anyhow, I have in atmel studio currently a breakpoint set at line that says PORTB.OUTCLR = PIN5_bm;    

 

I would think on debugging, code would run until breakpoint which means PORTB.OUTCLR would not get executed yet. (Pin 5 should be set as output, and nothing else should happen) then when you click F10 or continue, then PORTB.OUTCLR instruction WILL be executed.

 

I would think in this case, upon the execution of PORTB.OUTCLR, LED should turn on at that time, but not before. BUT the LED is already on when breakpoint is hit and I haven't moved on yet.

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

#define DELAY_TIME 100

int main(void)
{
     PORTB.DIR = PIN5_bm;
    
    while(1)
    {
        PORTB.OUTCLR = PIN5_bm;    
    }
}

 

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

theusch wrote:

I don't understand what the problem is.  If the LED is connected active-low, then indeed that would be expected operation.  You have not given us a schematic.

 

BTW, in your shown program, what do you expect to happen after the .DIRSET line?  I guess we can infer GCC, and then infer that most versions have a catch-loop after you run off the end of main()?

 

No warnings?  About lack of return value or otherwise?

I'm using AS7.

 

EDIT: brain fart. LED is not lighting up on my ATtiny1616, same xtiny series, whether active-low or active-high.  Info only, using PORTB pin 3 as ATtiny1616 SOIC20 does not have PORTB pin 5, would not make any difference though.

 

Also no compiler warning whatsoever.

------ Build started: Project: ATtiny1616SimpleBlinky, Configuration: Debug AVR ------
Build started.
Project "ATtiny1616SimpleBlinky.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\larry\OneDrive\Documents\Atmel Studio\7.0\ATtiny1616SimpleBlinky\ATtiny1616SimpleBlinky\ATtiny1616SimpleBlinky.cproj" (target "Build" depends on it):
 Task "RunCompilerTask"
  Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
  C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 2 --output-sync
  Building file: .././main.c
  Invoking: AVR/GNU C Compiler : 5.4.0
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.3.169\include" -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny1616 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny1616" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c"
  Finished building: .././main.c
  Building target: ATtiny1616SimpleBlinky.elf
  Invoking: AVR/GNU Linker : 5.4.0
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o ATtiny1616SimpleBlinky.elf  main.o   -Wl,-Map="ATtiny1616SimpleBlinky.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=attiny1616 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny1616" 
  Finished building target: ATtiny1616SimpleBlinky.elf
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "ATtiny1616SimpleBlinky.elf" "ATtiny1616SimpleBlinky.hex"
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "ATtiny1616SimpleBlinky.elf" "ATtiny1616SimpleBlinky.eep" || exit 0
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "ATtiny1616SimpleBlinky.elf" > "ATtiny1616SimpleBlinky.lss"
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "ATtiny1616SimpleBlinky.elf" "ATtiny1616SimpleBlinky.srec"
  "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "ATtiny1616SimpleBlinky.elf"
     text    data     bss     dec     hex filename
      164       0       0     164      a4 ATtiny1616SimpleBlinky.elf
 Done executing task "RunCompilerTask".
 Task "RunOutputFileVerifyTask"
    Program Memory Usage  : 164 bytes   1.0 % Full
    Data Memory Usage   : 0 bytes   0.0 % Full
 Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "ATtiny1616SimpleBlinky.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\larry\OneDrive\Documents\Atmel Studio\7.0\ATtiny1616SimpleBlinky\ATtiny1616SimpleBlinky\ATtiny1616SimpleBlinky.cproj" (entry point):
Done building target "Build" in project "ATtiny1616SimpleBlinky.cproj".
Done building project "ATtiny1616SimpleBlinky.cproj".

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Mar 15, 2018 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PORT registers are set to 0 on reset, so as soon as you set the bit (pin) as output it will be driving low.

 

Edit: added "(pin)"

David

Last Edited: Thu. Mar 15, 2018 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mc0134 wrote:
Yes the led on PB5 is active low.

So the LED is on when the pin is a low output (sinking).

 

So why are you confused?

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.

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

I'll look at the stuff later. I'm gonna get myself a new board and do a comparison. That's my goal for now. Thanks for the help everyone, will be back if there's still more issues.

 

EDIT: @ki0bk missed your post but a 1K resistor is in series with the LED.

Last Edited: Thu. Mar 15, 2018 - 08:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mc0134 wrote:
I'm gonna get myself a new board and do a comparison.

???  If you connect the LED on a "new board" active-low, as you stated, then indeed the LED will tiun on as soon as you make the pin a low (sinking) output.

 

Have you shown the schematic?

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.

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

@frog_jr, So using the DIRSET to set pin as output makes the pin go low already??? and what does OUTCLR really do in that case??? Just so I am clear.

 

 @theusch I was going to get a new board anyway so I would be doing a new test anyhow.

 

 

Ok. I'm off for now finally.

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

The port has to have some value on reset, the makers (Micromel) determined they would force it to 0.

When you enable it as an output, it is just outputting the value already in the port register.

OUTCLR will clear a value (if it is set); however, how can you clear a value that is already clear?

If you write to  OUTSET (or directly set the OUT register high) prior to enabling it as an output, the pin will drive high when set to be an output.

 

David