MSP430F233: Some Data gets lost on long Uart transmission

Bjoern Femerling

Part Number: MSP430F233

Hello!

I got a 8Mbit Serial Flash Memory connected to the MSP via SPI. The Flash is used to save measured Data with the Real Time. All values are saved as hexadecimal.

I coded a function to get the Data out of the Flash and send it via Uart to PC (Uart to RS232 converter on board and a RS232 to USB converter). In general there is no Problem with the communication. If all I do is sending the hexadecimal values everything works perfect.

The problem occurs if I modify the Data to have it transmitted in ASCII to be able to directly use it to save it in a .txt and work with the Data in Excel. I tried 2 different ways of conversion: Using Sprintf() or a Modulo operation to seperate each digit.

There are 65536 Data packages on the Flash. After filling the whole Flash with Data and reading it from PC with HTerm it happens that during the transfer of approximatly 40 completely random packages the MSP has some kind of hiccup. On the receiving side there is almost one whole package missing. It just continues in the next package from a little earlier. This leaves around 80 packages flawed which is not acceptable.

Since the hexadecimal transfer works it must be some issue for the MSP modifying the Data. First the code retrieves a whole package of 16 Bytes from Flash and saves each Byte in an array.

the code of the conversion with sprintf:

////////////////////////////

			char daten[10];
			sprintf(daten,"%d.",FLASH_ausgelesene_Daten[0]);
			Uart_print(daten);
			sprintf(daten,"%d.",FLASH_ausgelesene_Daten[1]);
			Uart_print(daten);
			sprintf(daten,"%d;",FLASH_ausgelesene_Daten[2]);
			Uart_print(daten);
			sprintf(daten,"%d:",FLASH_ausgelesene_Daten[3]);
			Uart_print(daten);
			sprintf(daten,"%d:",FLASH_ausgelesene_Daten[4]);
			Uart_print(daten);
			sprintf(daten,"%d;",FLASH_ausgelesene_Daten[5]);
			Uart_print(daten);
			sprintf(daten,"%d;",FLASH_ausgelesene_Daten[6]);
			Uart_print(daten);
			sprintf(daten,"%d;",FLASH_ausgelesene_Daten[7]);
			Uart_print(daten);

//this part converts into char splitted integers back into integers
			int Spannung,Temperatur,Strom,Druck;
			Spannung=(FLASH_ausgelesene_Daten[8]<<8)+(FLASH_ausgelesene_Daten[9]);
			Strom=(FLASH_ausgelesene_Daten[10]<<8)+(FLASH_ausgelesene_Daten[11]);
			Temperatur=(FLASH_ausgelesene_Daten[12]<<8)+(FLASH_ausgelesene_Daten[13]);
			Druck=(FLASH_ausgelesene_Daten[14]<<8)+(FLASH_ausgelesene_Daten[15]);

			char spannung[10],strom[10],temperatur[10],druck[10];
			sprintf(spannung,"%d;",Spannung);
			sprintf(strom,"%d;",Strom);
			sprintf(temperatur,"%d;",Temperatur);
			sprintf(druck,"%d",Druck);
			Uart_print(spannung);
			Uart_print(strom);
			Uart_print(temperatur);
			Uart_print(druck);
			Uart_SendByte(0x0A);

///////////////////////////

The F233 is quite small with only 8kB Flash and 1 kB RAM and I use it pretty much to its capabilities:

MSP430: Loading complete. There were 7568 (code) and 26 (data) bytes written to FLASH. The expected RAM usage is 829 (uninitialized data + stack) bytes.

Might it be the case, that the MSP has problems processing the conversion and therefor has these hiccups are does someone else have any idea?

We consider using the F235 with doubled Flash and RAM with the next boards, is it possible that the hiccups won't occur on the big brother?

I hope someone understands my Problem and can help me. I am trying a workaround by converting the Data on PC, but my lack of Skill with Visual Studio gives me issues there.

over 6 years ago

0 Clemens Ladisch over 6 years ago

Guru 244060 points

There might be a problem with your Uart_print/Uart_SendByte functions. Which you have kept secret.

0 Bjoern Femerling over 6 years ago in reply to Clemens Ladisch

Prodigy 100 points

void Uart_SendByte(char data)
{
	WDTCTL = WDTPW + WDTCNTCL;
	while (!(IFG2&UCA0TXIFG));	   				//transmit buffer ready?
	UCA0TXBUF = data;  							
}

void Uart_print(char *string)
{
	for(;*string;string++)						//for every byte til end of string
	{
		Uart_SendByte(*string);					//sending each byte
	}
}

don't think that is the problem. it works all perfect if I just do

	for(j=0;j<m;j++)							//loop for each data package
	{
		if(ADC12_strom_last <= 15000)
		{
			unsigned int i;
			for(i=0;i<16;i++)						//loop to get the 16 bytes from each package from Flash
			{
				if(j== (m-1) && i==15)				//condition to pull the CS of the Flash up after last byte to end data transfer
					letztes_byte=1;
				IE2 |= UCB0TXIE;							//Transmit interrupt for SPI
				FLASH_ausgelesene_Daten[i]=received_ch;		//save each byte temporarily (used for the modification part that hiccups some random data)
				Uart_SendByte(FLASH_ausgelesene_Daten[i]);
			}
		}
	}

I even tried to send all into ASCII modified Bytes with only Uart_SendByte() but still the same miscue.

I also encountered an issue when having just a little more expectet RAM usage (still beneath 900 but still room til the 1k accessable) in which variables in RAM got modified without them supposed to be. I traced it down to the point happening during sprintf() so I tried to get rid of as many RAM usage as possible to get rid of that issue.

That is why I think it is a problem of the MSP not working all to properly. It only happens if I modify the Data and it happens on extremely rare occassions. All possible interfering Interrupts (timer) are turned of as well.

0 Clemens Ladisch over 6 years ago in reply to Bjoern Femerling

Guru 244060 points

The UART code looks correct.

Your RAM problems are likely to be caused by the stack becoming too big (there is no built-in protection against that; when the stack grows too much, it simply overwrites other data). Try replacing sprintf() with itoa().

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F233: Some Data gets lost on long Uart transmission