Hello;
I am running the MSP430F2274 (CC2530 ZNP mini kit) examples for communication through UART. I have an FTDI USB 3.3V cable with USB on one end and UART RX and TX on the other. The hyper terminal and the receiving java program correctly receives the value from the MSP device. The MSP device is running in a loop and transmitting A-Z and this part of the functionality executes without any problem.
When I transmit from the java program the MSP interrupt for reception is not triggered. The problem then should lie in the java program / hyper terminal i.e on the transmitting side or the code of the MSP device on the receiving side. To eliminate the transmitting side, I looped back the RX and TX connections (on the UART side) of the FTDI's USB cable. The characters transmitted was correctly received on the console. This probably indicates that transmission till the MSP device is okay, which eliminates cable, connections (Rx/Tx) and settings. The transmission from the device was earlier tested indicating the baud rate and 8N1 to be correct on both sides. I dont know why the interrupts are not being triggered.
In the program shown below, which was tested on the device . If I change IE2 |= UCA0RXIE ; to IE2 |= UCA0TXIE;, then the output prints Hello World.
The initializing code for UART is working on the kit. Any ideas, what mistake, am I committing? any additional set up required?
const char string1[] = { "Hello World\r\n" };unsigned int i;void main(void){ WDTCTL = WDTPW + WDTHOLD; // Stop WDT BCSCTL1 = CALBC1_1MHZ; // Set DCO DCOCTL = CALDCO_1MHZ; P3SEL = 0x30; // P3.4,5 = USCI_A0 TXD/RXD UCA0CTL1 |= UCSSEL_2; // SMCLK UCA0BR0 = 104; // 1MHz 9600 UCA0BR1 = 0; // 1MHz 9600 UCA0MCTL = UCBRS0; // Modulation UCBRSx = 1 UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine** IE2 |= UCA0RXIE ; // Enable USCI_A0 RX interrupt + UCA0TXIE __bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled }#pragma vector=USCIAB0TX_VECTOR__interrupt void USCI0TX_ISR(void){ UCA0TXBUF = string1[i++]; // TX next character if (i == sizeof string1 - 1) // TX over? IE2 &= ~UCA0TXIE; // Disable USCI_A0 TX interrupt}#pragma vector=USCIAB0RX_VECTOR__interrupt void USCI0RX_ISR(void){ if (UCA0RXBUF == 'u') // 'u' received? { i = 0; IE2 |= UCA0TXIE; // Enable USCI_A0 TX interrupt UCA0TXBUF = string1[i++]; }}
Your code looks fine. And TX seems to work fine too, since if you enable TXIE manually, the hello world text gets properly transmitted.So my first guess would be the RX connection. Bad soldering ot something like that. Or the TX line is somehow tied to gnd/VCC, so the FTDI signal is overridden. Did you check the schematic? Is this line hardwired to the FET on your kit?
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Hi Jens-Michael,
The code works fine if I poll and remove all the interrupts. This also eliminates the connection issues that you mentioned. I do agree that I have used wires to temporarily connect the two connections along with the ground.
At present, I am using polling in my code to overcome this issue. I still feel that there might be some software / coding issue on the MSP device. Being an evaluation kit, does TI disable features? I don't think that would be the case.
I prefer the interrupts but I have the code working for now. And I am using it to get over for this demo project.
Cheers,
DAC
I looked at your code several times over the last week (it's still on an open tab). But I don't have a clue what's wrong.Well, 'i' should be volatile, but it doesn't matter here (unless you want to check the current state of i in main)
As you said, it is working when polling, so port and USCI setup and hardware are okay. And the TX ISR is working too.
Sure, there's always the possibility of a hardware defect, but this would be a very, very unlikely one.
I don't have any clue what's wrong with the code you posted. After all, the code isn't that complex.