TXBUF and RXBUF

The register names are different. Try UCA0TXBUF and UCA0RXBUF
Note that not all of the LaunchPad processors have a hardware USCI module. (in fact only the latest one has).

Anyway, the TXBUF or RXBUF are holding only one single byte (the jsut received and the lnext to transmit) and are not meant for data storage.

If this isn't the solution, you should post your code and the exact error message.

Hi,

Use the register variable as mentioned in the hearer files of the corresponding chip.

Hi,

When a byte sent from the PC, I noticed in the CCS5 that not only the UCA0RXBUF has the data but also the UCA0TXBUF was updated with the same data byte.  At the same time, the bit UCA0RXIFG is not set.  Would you please point to an area to look.

Thank you.

Hi,

I found my problem. 

Thank you.

If you would share your solution others could benefit from it, too.

I need to share my encounter with this community:
Here is the original code:
i = 0x0; // . . Reset index for transmit ISR
IE2 |= UCA0TXIE; // . . Enable USCI_A0 TX interrupt. At end of 10 repeated int,
cSnoop = TRUE; // . . start listening to the Serial bus again
i = 0x0; // . .

Interrupt occurs after the IE2 |= UCA0TXIE. In the ISR routine (not shown), the code moves a byte into the UCATXBUF register, increments the index pointer, and drops back down. Most of the time, the MSP430G2413 was able to emptied out the Buffer and reactivates the interrupt flag, such that, the instant control is back at base level, hardware interrupts the code right back up into the ISR. The real problem, as I have endured the hair loss and wonderment, was that, at times, interrupt did not occur until after the first instruction (cSnoop = TRUE), or even after the second instruction (i = 0x0). Needless to say, controls are all messed up.

Once the problem is understood, the fix was easy and straight forward, i.e., double check the hardware status. Since, at the end of transmission, the interrupt is disabled by the ISR, to overcome the problem, I added the check (while (IE2 & UCA0TXIE)). Here is the code that works:
i = 0x0; // . . Reset index for transmit ISR
IE2 |= UCA0TXIE; // . . Enable USCI_A0 TX interrupt. At end of 10 repeated int,
while (IE2 & UCA0TXIE); // . . (Tag=1: Added to solve the problem with MSP430G2413 not re-interrupt in time)
cSnoop = TRUE; // . . start listening to the Serial bus again
i = 0x0; // . .

By the way, about my post on Dec 5, the problem I have found then was an over sight, in that I left in the code, the copying of data from the UCARXBUF to the UCATXBUF register (Shy).

The way you describe it, it seems that the TX event is already pending when you set TXIE, and you expect it to have been handled before you proceed. But sometimes the TX event happens later and this messes up your code flow. A typical case of a race condition.
Your waiting loop synchronizes the data transmission with the main code flow. So it solves the racing condition. It is, however, not the best you can do. It is busy-waiting. Interrupts are there to handle things in the background, or you could as well not use interrupts but check the IFG bits during main code (polling). You should rework your concept, with a less ‘sequential’ approach in mind.

Hi Aravind, 

As you written , it seems that you are writing some wrong spell of TXBUF. Anyway if you are using the FIFO module with SCI. and want to transmit the train of bytes , first you have to check the FIFO level and the then make any for loop of same length and transmit it one by one till last byte. Now the FIFO pointer again will point to zero. But make sure that you dont reset FIFO pointer manual just after Tx the bytes.

For receiveing first Reset FIFO pointer and check for FIFO level when if fills till the desired value as you compare , make a for loop and receive all one by one.

like this for(i=0;i<16;i++) value[i]=RXBUF;

All the best

Ashutosh Bhatt