Atxmega256A3U usart receive problem

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

Hi 

I am very confused to communicate between sim800 and xmega in Atmel Studio 6.2, I set baud rate 9600 and use USARTD on PORTD it works fine in one xmega but it may be lost because of VCC gnd short circuit, I use another one but send is ok and sms can send by my command to sim800 but when I want to receive data it does not work properly and receive "AT" instead of my sms. here is the code of usart initial and clock set to 32mhz internal:

    PORTD.DIRSET   = PIN7_bm;
    PORTD.DIRCLR   = PIN6_bm;
    USARTD1_BAUDCTRLA=0xCF; //for baud rate 9600, BSEL=12, BSCALE=4 as per data sheet
    USARTD1_BAUDCTRLB=0x00; //BSCALE=4, upper 4 bits out of 12 bit used for USART baud rate setting will be zero
    USARTD1_CTRLB|=USART_RXEN_bm|USART_TXEN_bm; //enable USART receiver and transmitter
    USARTD1_CTRLC|=USART_CHSIZE1_bm|USART_CHSIZE0_bm; //asynchronous mode, 8-bit character size, 1 stop bit, no parity

sms receive code:

for (sms_n=0;sms_n<=100;sms_n++){
 sms[sms_n]=Null;}

 end_message=0;sms_n=0;

 sendString("AT+CMGF=1\n\r");_delay_ms(250);
 sendString("AT+CMGR=1\n\r");_delay_ms(1000);
 sendString("AT+CMGR=1\n\r");
 //read sms

 while(end_message==0)
 {
 rec=usart_receiveByte();
   if(rec==Null)
   {
   }

   else if (((rec==LF || rec==CR)) && sms[1]!=Null)
   {
	   end_message=1;
   }

   else
   {
	   if(sms_n>=100)
	   {
	   }
	   else
	   {
		sms[sms_n]=rec;
		sms_n++;
	   }
     }
 }

and receive function:

char usart_receiveByte()
{
    while( !(USARTD1_STATUS & USART_RXCIF_bm) );
    return USARTD1_DATA;
}

I tested my sim800 with Arduino Uno it works perfectly.

Last Edited: Sun. Jun 7, 2020 - 06:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting.

 

AT is a Hayes command.  Invented around 1980 to test and control dialup modems.  Now I see it can be used with smart phones.

 

https://www.engineersgarage.com/...

 

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

steve17 wrote:
Now (sic) I see it can be used with smart phones.

Go on.

 

GSM modules have had AT Command interfaces from the outset - it is part of the GSM specs.

 

(actually, they are trying to do away with it now - internally, they'll be using QMI)

 

AT Commands have long been the de facto standard for controlling & communicating with any "DCE-like" device; eg,

 

  • Cellular modules
  • Bluetooth (including BLE) modules
  • WiFi modules
  • LoRa Modules
  • etc, etc, ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saleh_hp wrote:
I am very confused to communicate between sim800 and xmega

When confused, the first step is always to simplify the question.

 

In his tutorial, 'Help! It doesn't work!',  Kartman wrote:
3. Ask yourself “how many problems do I want to solve at once”? The answer should be one. Trying to solve more than one problem at a time is a recipe for failure. 

 

https://www.avrfreaks.net/forum/help-it-doesnt-work

 

Fundamental to AT Commands is having good, solid, reliable, robust serial comms.

 

So your first step should be to take a step back, forget about the SIM800, and just concentrate on getting your serial comms solid.

 

Start by ensuring that your AVR can communicate reliably over a simple, direct, wired connection to a PC running a terminal program.

 

See the Tips in my signature (below) for some common serial interfacing problems.

 

See https://www.avrfreaks.net/commen... for some tips on debugging serial comms

 

See https://www.avrfreaks.net/commen... for some tips on debugging in general.

 

#DebugATCommands.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jun 15, 2020 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

steve17 wrote:

Now (sic) I see it can be used with smart phones.

 

Go on.

 

GSM modules have had AT Command interfaces from the outset - it is part of the GSM specs.

 

Yeah but I'm still using landline dial-up modems.  smiley  Actually I switched a few months ago to landlineless phones because the monthly bills are less although their care and feeding are a pain in the azz.

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

saleh_hp wrote:

 sendString("AT+CMGF=1\n\r");_delay_ms(250);
 sendString("AT+CMGR=1\n\r");_delay_ms(1000);
 sendString("AT+CMGR=1\n\r");

Two classic mistakes right there:

 

  1. The command terminator is just CR; not LF - and certainly not the LF first!
    https://www.avrfreaks.net/commen...
     
  2. Blind Delays
    https://www.avrfreaks.net/commen...

 

But getting the basic serial comms right remains the first priority! 

 

EDIT

 

Fix quote

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jun 15, 2020 - 11:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 sendString("AT+CMGF=1\n\r");_delay_ms(250);
 sendString("AT+CMGR=1\n\r");_delay_ms(1000);
 sendString("AT+CMGR=1\n\r");

Just spacing AT commands with delays (and presumably assuming they always "OK" and never give some kind of error response) is not a great approach to driving Hayes interface devices. You should have a state machine that expects every possible response that every command could produce and handle the response whatever it may be.

 

Sure there may be some commands that only ever respond "OK" but even for those you should not simply delay(250) or delay(1000) or whatever but actually confirm you have seen 'O then 'K' and then carry on with the next command in sequence.

 

You may "get away" with this in the early days and using a few simple commands but as you go on to exercise the modem command set more you will gig a deeper and deeper hole for yourself if you don't design a a command/response handling system from the outset.