AVR studio 4 - am I doing these fuses right?

[o_0]

Hi,

I am trying to use a 3.6864 MHz external crystal on an ATmega32a. I set the fuses as "Ext. Crystal/Resonator Medium Freq.; Start-up time. 1K CK + 4 ms (CKSEL=1100 SUT=11)." When I click verify, the message is "Reading fuses...0x99, 0xFC...OK!" Are these the correct settings? I'm asking because I'm trying to troubleshoot.

Thanks

By the way, using STK500

 

[ctownsend]

this may help you:
Engbedded AVR Fuse Calculator

 

[ashokok]

I'm trying to troubleshoot.

What is the trouble??

The JTAG interface is enabled.
do you know the pull-up resistors will be active on pins PC5, PC3 and PC2 if JTAG interface is enabled.

P.Ashok Kumar

 

[Tahmid]

Hi,
The clock setting for use with 3.6864MHz crystal should be CKSEL3...0 -> 1110, not 1100 CKOPT=1. This sets the crystal mode to 3-8MHz external with 1CK + 4ms startup time.

Hope this helps.
Tahmid.

 

[o_0]

To ctownsend:

Thanks, but I had that info already in AVR Studio, I'm just not sure what settings I should give it. For instance, is 3.6864 MHz considered low or medium frequency? Also, I don't think I care about the startup time, do I? (update: someone else answered this; according to other responses, it's apparently considered medium.)

To ashokok:

---Quote (Originally by o_0)---
I'm trying to troubleshoot.
---End Quote---
What is the trouble??

Oh, everything. I'm trying to do a UART wireless link, and on the transmitter uC the TX pin is always high no matter what the RX pin is, even if Vcc is disconnected. I will post more info about it in a little while when I can get to my own computer.

Also, when compiling the code I was getting the error "Object file not found on expected location", but I clicked on the Build tab and it says "Build succeeded with 0 warnings" but still there is no hex file generated. I compiled the exact same code on a different computer (same exact version of AVR studio) and there are no errors and the hex file is generated. So what's the problem, you ask? Why not just use the working computer? Well, that one has no serial port or working USB ports. I could just email the data and download it on the other computer, but as you might imagine that's quite inconvenient and I would rather have the other one just working. It wasn't doing this before. Also, I reinstalled the program or anything. The non-working computer has viruses, could that be the problem?

------------
The JTAG interface is enabled.
do you know the pull-up resistors will be active on pins PC5, PC3 and PC2 if JTAG interface is enabled.

- Doesn't this just mean Port C won't work properly? I'm not using Port C right now but will keep that in mind if I decide to use it in future. Thanks.

To Tahmid:

Thanks a lot, I'll try that.

 

[Tahmid]

Hi,
Yea, I think it's medium frequency. It's like <3MHz is low frequency, 3-8MHz is medium, >8 is high frequency.
As for the compiler error thing, there might be an error in the setup. Uninstall your application completely, not with Windows Add/Remove but something like Revo Uninstaller that deletes all removing files including registry files. After un-installation, reinstall AVR Studio and try again.
There was a problem with MPLAB C18, I remember, similar to yours, if the un-install,reinstall doesn't work, I'll tell you about it.

Hope this helps.
Tahmid.

 

[ctownsend]

What is the trouble??

Oh, everything. I'm trying to do a UART wireless link, and on the transmitter uC the TX pin is always high no matter what the RX pin is, even if Vcc is disconnected. I will post more info about it in a little while when I can get to my own computer.

post your code and schematic, someone may help you.

 

[o_0]

AVR studio is working fine now just by rebooting the computer (not uninstalling anything), must have been the virus.

Thanks for your interest.
Sorry for the delay, I made 2 versions of the circuit, a UART transmitter/receiver pair. They are set up more or less exactly as the diagrams on this webpage.
WinAVR AVR-GCC Tutorial (<-- click)

The two versions are very similar except in Version 1, the input to the transmitter is generated internally, transmitting 0x55 continuously. In Version 2, the input to the transmitter is external, hooked up a wire either to ground or Vcc. (In this case, the code for the transmitter and receiver is the same.) Version 1 only differs by two lines of code in the transmitter.

Here are voltage measurements for some pins that I thought were relevant. When a range is given, it means the measurement oscillated but spent most of its time in the middle of that range.
Version 1:
Transmitter: Rx=0, Tx=2.72 V, Data pin of TX434=2.72
Receiver: Data pin of RX434=0.68-0.8, Rx=0.59-0.69, Tx=4.82-4.84

Version 2:
(Case 1: Rx pin of transmitter held at 0)
Transmitter: Rx=0, Tx=4.99, Data pin of TX434=4.99
Receiver: Data pin of RX434=1.1-1.2, Rx=1.15-1.3, Tx=0

(Case 2: Rx pin of transmitter held at +5V)
Transmitter: Rx=4.99, Tx=4.99, Data pin of TX434=4.99
Receiver: Data pin of RX434=1-1.2, Rx=0.74-0.94, Tx=0

I have Proteus simulations too if you want to see them.
(Code in next post...)

---------- Post added at 05:50 ---------- Previous post was at 05:38 ----------

Version 1 code:

#include <avr/io.h>


#include <util/delay.h>

void USART_Init( unsigned int baud )
{
   /* Set baud rate */
   UBRRH = (unsigned char)(baud>>8);
   UBRRL = (unsigned char)baud;
   /* Enable receiver and transmitter */
   UCSRB = (1<<RXEN)|(1<<TXEN);
   /* Set frame format: 8data, 2stop bit */
   UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
}

void USART_Transmit( unsigned char data )
{
   /* Wait for empty transmit buffer */
   while ( !( UCSRA & (1<<UDRE)) )
   ;
   /* Put data into buffer, sends the data */
   UDR = data;
}

unsigned char USART_Receive( void )
{
   /* Wait for data to be received */
   while ( !(UCSRA & (1<<RXC)) )
   ;
   /* Get and return received data from buffer */
   return UDR;
}

//void delayms(uint8_t t)//delay in ms

//{

//uint8_t i;

//for(i=0;i<t;i++)

//	_delay_ms(1);

//}




int main(void)
{
   volatile uint8_t x; 
   //char x;
   USART_Init(95); // 
                  //this is the UBRR value, calculated from UBRR=fosc/(16(baud+1))
   
      while(1)
      {
      x=0x55;
	  //x=USART_Receive();
//	  delayms(100);
      USART_Transmit(x);
      }
   return(0);
   }

Version 2 code (in both versions, this is the receiver code)

#include <avr/io.h>


#include <util/delay.h>

void USART_Init( unsigned int baud )
{
   /* Set baud rate */
   UBRRH = (unsigned char)(baud>>8);
   UBRRL = (unsigned char)baud;
   /* Enable receiver and transmitter */
   UCSRB = (1<<RXEN)|(1<<TXEN);
   /* Set frame format: 8data, 2stop bit */
   UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
}

void USART_Transmit( unsigned char data )
{
   /* Wait for empty transmit buffer */
   while ( !( UCSRA & (1<<UDRE)) )
   ;
   /* Put data into buffer, sends the data */
   UDR = data;
}

unsigned char USART_Receive( void )
{
   /* Wait for data to be received */
   while ( !(UCSRA & (1<<RXC)) )
   ;
   /* Get and return received data from buffer */
   return UDR;
}

//void delayms(uint8_t t)//delay in ms

//{

//uint8_t i;

//for(i=0;i<t;i++)

//	_delay_ms(1);

//}




int main(void)
{
   char x;
   USART_Init(7); // 
                  //this is the UBRR value, calculated from UBRR=fosc/(16(baud+1))
   
      while(1)
      {
      x=USART_Receive();
//	  delayms(100);
      USART_Transmit(x);
      }
   return(0);
   }

Here's another thing, the checkbox for "Serial program downloading (SPI) enabled; (SPIEN=0)" is grayed out (can't click it) and there's a red question mark by it, I'm not using SPI but I just thought I should mention it. This is the case for all the uC right out of the box.