This RAM data looks right to you?

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

I have been working in a code that was running just  fine, but I had to pause for some days. Today I get back to this very same code and it is broken. I did not changed anything since last time. Looks to me something went wrong with Atmel Studio 7. One thing intriguing me is the RAM data. I did not remember to have more than half of my RAM space taken by this data (see image). Since I´m a kind of newbie in C, is normal all this data from function Init_GSM be in the RAM? I thought the first string would be superposed by the second and so on. Other very suspect behavior (to me) is all the text from strings all over the code, even ones not used yet, shows in the RAM space.

This RAM data looks right to you? Or I did something stupid since the beginning which lead to this now?

void TX_GSM_String (char* String)
{
	for (int i = 0; i < strlen(String); i++)
	{
		while (( UCSR0A & (1<<UDRE0))  == 0){};
		UDR0 = String[i];
	}
}
void Init_GSM (void)
{
	POWERKEY_HIGH;
	_delay_ms(400);						// This start
	POWERKEY_LOW;
	_delay_ms(1200);
	POWERKEY_HIGH;
	TX_GSM_String("AAAA");				//Send 4x "A" to auto baud fix at 9600
	_delay_ms(500);
	TX_GSM_String("ATE0\r\n");			//Echo off OK
	_delay_ms(500);
	TX_GSM_String("AT+CMGF=1\r");		//Set SMS Text mode OK
	_delay_ms(500);
	TX_GSM_String("AT+CNMI=1,2,0,0,0\r");	//Shows contents of new SMS OK
	_delay_ms(500);
	TX_GPS_String("$PSRF103,1,0,0,1*25\r\n");	//Disables GPGLL
	_delay_ms(100);
	TX_GPS_String("$PSRF103,2,0,0,1*26\r\n");	//Disables GPGSA
	_delay_ms(100);
	TX_GPS_String("$PSRF103,3,0,0,1*27\r\n");	//Disables GPGSV
	_delay_ms(100);
	TX_GPS_String("$PSRF103,5,0,0,1*21\r\n");	//Disables GPVTG
	_delay_ms(100);
	TX_GPS_String("$PSRF103,0,0,2,0*20\r\n");	//GPGGA every 10s
	_delay_ms(100);
	TX_GPS_String("$PSRF103,4,0,2,0*24\r\n");	//GPRMC every 10s
}
int main(void) {
	DDRA=0b00011001;		//PA4=LED
	PORTA=0b00000000;
	DDRB=0b00001010;
	PORTB=0b00000010;
	DDRD=0b00000000;
	PORTD=0b00000000;
	
	uint8_t baud = 25;
	
	UBRR1H = (unsigned char) (baud >> 8);// define baud GPS
	UBRR1L = (unsigned char) baud;
	UCSR1B = (1<<TXEN1) | (1<<RXEN1);		// Turn GPS Serial on
	UCSR1C = (1<<UCSZ10) | (1<<UCSZ11);		// 8 bit
	UCSR1B |= (1 << RXCIE1);
	UBRR0H = (unsigned char) (baud >> 8);	// define baud GSM
	UBRR0L = (unsigned char) baud;
	UCSR0B = (1<<TXEN0) | (1<<RXEN0);		// Turn GSM Serial on
	UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);		// 8 bit
	
	sei();
	Init_GSM();

	while(1) {
		LED_ON;
	}
}

 

Attachment(s): 

This topic has a solution.

Good Soldering JRGandara

Last Edited: Tue. Jul 28, 2015 - 07:06 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I found out after some more hours researching. Why simplify if we can make things complex?

http://www.atmel.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_introduction.html

Good Soldering JRGandara

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

Note that PROGMEM has been superceded by __flash which is a "better" solution as you don't need pgm_read_*() access to dereference the data.

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

CLiff,

 

I would have thought that would have made it to the manual, but the manual the OP is pointing to still holds PROGMEM.

When searching for "_flash" that yields no results.

So I can imagine that someone who is searching fro information on how to put things in flash still ends up using the PROGMEM attributes and functions.

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

Marcel,

 

You are wrong. PROGMEM is a featured added by AVR-LibC so naturally it is covered in the AVR-LibC manual (linked above). __flash on the other hand is a feature of the GCC compiler itself (which is why it is "better") so it is documented in the GCC user manual:

 

https://gcc.gnu.org/onlinedocs/g...

 

Remember that the ./doc/ directory in a GCC (AVR) installation contains more than just the AVR-LibC manual. There are manuals for AVR-LibC, avr-gcc, avr-as, avr-ld, bfd, avr-objcopy, avr-objdump, avr-ar, avr-nm and other binutils. The collected information to use the compiler and associated tools is spread across them all.