Problems with Atmel Studio 7, JTAGICE mkII, Atmega48p, and LED-blinking C project

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

After a ~5-year hiatus from AVR development (with occasional Arduino development in the meantime), I've decided to dig back in to my small mountain of bare AVR chips (my Atmega48p chips, in particular) and put them to good use.

 

Things I've done:

 

1. Installed Atmel Studio 7 (v7.0.1645).

 

2. Put an Atmega48p in a breadboard, along with a 5v breadboard-friendly power supply, a LED, a resistor, and an ISP-header breakout board from Sparkfun & wired everything up (LED anode to 5v, cathode to resistor, other end of resistor to pin 14/B0)

 

3. Connected my JTAGice mkII to the ISP header. At some point, Atmel Studio updated its firmware (from v21 to v27, I believe).

 

4. Created a new project in Atmel Studio:

  1. File -> new -> project, "GCC C Executable Project"
  2. Selected ATmega48P from device list.
  3. Updated the auto-created main.c to look like this:

 

#include <avr/io.h>

int main(void)
{
    DDRB = 0xff;
    PORTB = 0xff;
    /* Replace with your application code */
    while (1)
    {
    }
}

 

5. Build-> Build Solution

No apparent errors:

------ Build started: Project: GccApplication3, Configuration: Debug AVR ------
Build started.
Project "GccApplication3.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\root\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\GccApplication3.cproj" (target "Build" depends on it):
    Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
    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 8 --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\ATmega_DFP\1.2.150\include"  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega48p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.150\gcc\dev\atmega48p" -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: GccApplication3.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 GccApplication3.elf  main.o   -Wl,-Map="GccApplication3.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega48p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.150\gcc\dev\atmega48p"  
        Finished building target: GccApplication3.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  "GccApplication3.elf" "GccApplication3.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 "GccApplication3.elf" "GccApplication3.eep" || exit 0
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication3.elf" > "GccApplication3.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 "GccApplication3.elf" "GccApplication3.srec"
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication3.elf"
           text       data        bss        dec        hex    filename
             82          0          0         82         52    GccApplication3.elf
    Done executing task "RunCompilerTask".
    Using "RunOutputFileVerifyTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
    Task "RunOutputFileVerifyTask"
                Program Memory Usage     :    82 bytes   2.0 % Full
                Data Memory Usage         :    0 bytes   0.0 % Full
    Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "GccApplication3.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\root\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\GccApplication3.cproj" (entry point):
Done building target "Build" in project "GccApplication3.cproj".
Done building project "GccApplication3.cproj".

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

6. Debug -> Start without debugging (error: Please select a connected tool and interface and try again)

 

7. Selected JTAGice mkII with ISP, hit ctrl-s to save

 

8. Debug -> Start without debugging. Seems to have completed without problems:

 

------ Build started: Project: GccApplication3, Configuration: Debug AVR ------
Build started.
Project "GccApplication3.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\root\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\GccApplication3.cproj" (target "Build" depends on it):
    Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
    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 8 --output-sync
        make: Nothing to be done for 'all'.
    Done executing task "RunCompilerTask".
    Using "RunOutputFileVerifyTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
    Task "RunOutputFileVerifyTask"
                Program Memory Usage     :    82 bytes   2.0 % Full
                Data Memory Usage         :    0 bytes   0.0 % Full
    Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "GccApplication3.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\root\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\GccApplication3.cproj" (entry point):
Done building target "Build" in project "GccApplication3.cproj".
Done building project "GccApplication3.cproj".

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

And... nothing.

 

According to my logic probe, pins 1 (RST), 7 (Vcc), and 20 (AVcc) are high, pins 8 (Gnd) and 22 (Gnd) are low, and the remaining pins all appear to be tristate. Since RST is explicitly high, I'm pretty sure the chip isn't stuck in reboot. I checked Vcc at the pin with a meter, and got 5.05v (so it's definitely not a brownout-related issue, either).

 

I also tried setting the port to 0 instead of 0xff, tried with DDRB/PORTD and DDRC/PORTC, and using explicit values (1, 2, 4, etc) instead of 0xff. No luck.

 

I confirmed that "start without debugging" is definitely causing the JTAGice mkII to do SOMETHING... the LEDs on the JTAGice go from green-orangered-red to green-orangered-green for a moment, and watching the SCK/MISO/MOSI lines with the probe indicates that SOMETHING is definitely happening there.

 

I know it's probably due to something stupid that I've just forgotten about over the past few years, but I'm not really sure what to try next. Any ideas?

There's no place like ~/

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

LED anode to 5v, cathode to resistor, other end of resistor to pin 14/B0

 PORTB = 0xff; 

 

And... nothing.

And what did you expect to happen? Don't say the LED should turn on. wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Where are the bypass caps between Vcc and common? You need at least a 0.1uf from each power supply pin to common.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

OK, that part wasn't quite clear... I also tried PORTB = 0x00, and still got the same result. Also, I forgot to mention the .1uF cap between pins 7 and 8 :-)

 

The big thing that's weird is the fact that the logic probe sees literally NOTHING on the other pins... not high, not low. NOTHING (presumably, tristate). It sees high on pins that are guaranteed to be high by virtue of their external connections or function (RST, Vcc, AVcc) or low by virtue of being a ground pin, but when I touch the probe to the OTHER pins, I might as well be touching the breadboard's plastic.

 

Actually... I just thought of something... is there a combination of fuses that would leave the chip (seemingly) programmable via ISP, but with all of its IO pins appearing to be dead? As far as ISP goes, everything seems to be working fine... I can read the chip ID and flash it without overt errors, but I can't help wondering whether this might be one of the chips I killed with DebugWire a few years ago. From what I recall, there was a bug/design-flaw where the chip would get stuck in DebugWire mode & nothing short of high-voltage programming could fix it... is that now ancient history, or is DebugWire as screwed up and unsafe to use (in any context where the chip can't be removed and fixed via HVSP) now as it was back then?

There's no place like ~/

Last Edited: Mon. May 28, 2018 - 12:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you test your led/resistor with 5V  to verify?

Backwards?  Wrong resistor?  Check with 5V!

 

Did you program your chip?  WHERE?  You only mention compiling.

 

Compile program (simply press  F7)

TOOLS...DEVICE PROGRAMMING...

Select your programming tool, if not already selected.

Hit APPLY      Hit READ device signature...good so far?  If not, check your chip & cables.

Some programmers apply power to the chip, other require you to provide the power.

 

Under MEMORIES

select your hex file  & press PROGRAM

When in the dark remember-the future looks brighter than ever.

Last Edited: Mon. May 28, 2018 - 02:44 PM