Replacing ATMEGA16 with ATMEGA88: No success

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
joakimk
joakimk's picture
Level: Rookie
Joined: Sun. Feb 25, 2007
Posts: 33 View posts
#1
Posted by joakimk: Sun. Dec 8, 2019 - 11:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone!

 

I'm working on a blinking-lights project, where the twist is that the blinking is to be controlled over wifi using ESP8266 modules to receive data. My project has come to the point where I can receive data over wifi -> UART/serial into the ATMEGA16, which then blinks the LEDs on the STK500 (PORTB).

 

Next, I want to change the AVR to ATMEGA88 -- simply because they are smaller, and I have a whole bunch of them (I aim to make several receiver unit to run in parallel). However, changing the device proves to be quite involved. I realize there are many differences between these two hardware architectures, and I have compared the datasheets to update the UART init, but I just can't seem to get the ATMEGA88 to run "at all". It's proofs of life should be: light up LEDs on the STK and/or transmit something over UART (to the ESP, which I intercept through the RS232 SPARE and to a terminal on my PC). Nothing!

 

To isolate the problem, I created the following bare-bones ATMEGA88 project, which does not light up any LEDs:

 

#include <avr/io.h>

int main(void)
{
	DDRB = 0xFF; // set PORTB for output
	PORTB = 0b01111111; // crash indicator (LED 7)

    /* Replace with your application code */
    while (1)
    {

    }
}

Plase find attached a photo of the setup on my STK. Also, reading fuses and programming/verifying the HEX works fine in Atmel Studio.

 

 

Thanks!

 

Joakim

 

 

Attachment(s): 

Image icon DSC_0364.JPG
This topic has a solution.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, STK500 Atmel Studios 7, solved, ATmega88
Last Edited: Sun. Dec 8, 2019 - 09:35 PM
Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39611 View posts
Location: Wisconsin USA
This reply has been marked as the solution. 
Posted by theusch: Sun. Dec 8, 2019 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joakimk wrote:
I created the following bare-bones ATMEGA88 project, which does not light up any LEDs:

LEDs on STK500 are active low.

 

Depending on your fuses, PB6 and PB7 are clock pins.

 

What does a voltmeter say?  Follow all the way from the pin to the V source.

 

Use a pattern such as 0x55 as a sanity check.

 

Is your AVR actually running, and not held in reset?  Or brownout?

 

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.

Top
joakimk
joakimk's picture
Level: Rookie
Joined: Sun. Feb 25, 2007
Posts: 33 View posts
Posted by joakimk: Sun. Dec 8, 2019 - 05:06 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, active low, as where 0b0111111 should light up LED7. The AVR is running in the STK500, so I don't know if tracing the voltage is the key here? How can I check if the AVR is running/brownout while it's sitting in the STK? This is what I was using the LED7 "crash indicator" for (since, if the firmware crashes, the chip will reset, and the LED will be held on):

Something like,

 

main() {
  DDRD = 0xFF;
  PORTD = 0b0111111;
  _delayms(500);
  // other init, like uart etc
  PORTD = 0xFF; // indicator off

   while (1) {
     // main program logic....
   }
}

 

I'll check the fuses wrt PB6 and 7, thanks for the tip! In fact, I'll just try connecting LEDs to PORTD instead of B. I'll also try a different pattern, like 0x55.

Last Edited: Sun. Dec 8, 2019 - 05:18 PM
Top
joakimk
joakimk's picture
Level: Rookie
Joined: Sun. Feb 25, 2007
Posts: 33 View posts
Posted by joakimk: Sun. Dec 8, 2019 - 09:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again for the clue on PB6 and 7 being reserved, depending on fuses. Now I know the ATMEGA88 is indeed running its program (there are other challenges, though, but I'll put those in a different post).

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39611 View posts
Location: Wisconsin USA
Posted by theusch: Mon. Dec 9, 2019 - 12:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joakimk wrote:
The AVR is running in the STK500, so I don't know if tracing the voltage is the key here?

Think about it.  Your complaint is that the lights are not lighting up.  So do some measuring, using the STK500 schematics if needed.  What does that tell you about code? 

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.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97842 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Dec 9, 2019 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I seem to remember that because of the XTAL1/XTAL2 thing that for 28 pin chips the PB6/PB7 may come out on the PE6/7 pins (it was ~15 years since I last faced this so my memory is sketchy!)

Top
david.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 29381 View posts
Location: Wormshill, England
Posted by david.prentice: Mon. Dec 9, 2019 - 01:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes.   You must use the PORTE/AUX header to access PB6, PB7 on a mega88.   (my distant memory)

 

And obviously set the clock fuses for Internal 8MHz RC first.

 

David.

Last Edited: Mon. Dec 9, 2019 - 01:06 PM
Top