CCS/MSP430FR5994: The UCRXIFG interrupt flag is not set in the process of program running for Hardware SPI (eUSCI_B SPI)

Hello,

one quite probable reason for the observed issues is the polling of the flag. Why are you using polling of interrupt flags, especially RX, which with high probability is asynchronous to CPU activities? You have to keep in mind the RX interrupt flag and related logic might try to write into the register at the time when the CPU is accessing it. This might generate race conditions. Thus I would definitely recommend you using an interrupt service routine for handling the interrupt flags.

This actually applies to any interrupt flags, not only for communication.

Best regards

Peter

I hesitate to disagree with Peter, but this is a case (fast SPI) where polling the RXIFG is quite reasonable. I do this all the time, but I haven't seen the symptom you describe. My first guess is that you're accidentally/occasionally clearing the RXIFG by something else you're doing.

Please post the code you're using to talk to the SPI.

//Hardware SPI Read/Write one Byte
uint8_t UCB2_SPI_WR_Byte(uint8_t dw)
{
 //while ( !(UCB2IFG&UCTXIFG) );
 UCB2TXBUF = dw;
 while ( !(UCB2IFG&UCRXIFG) );

 return UCB2RXBUF;
}

I also do this all the time, and I've never had this problem before.

Relevant registers are operated only in this function

It is not the first communication that fails, but it suddenly appears in the process of communication. Some MCUs will have this phenomenon in a few minutes, and some in a few hours.A small number of MCUs can work properly without this problem. This problem can also occur when abnormal MCUs are switched to normal circuit boards. Normal MCUs have never had this problem.

If an exception occurs, the program is waiting for UCRxIFG to be set all the time, and UCTXIFG is not set. Normally, when waiting for the UCRxIFG flag, UCTXIFG  flag will be set.Why UCTXIFG is not set.

It is not the first communication that fails, but it suddenly appears in the process of communication. Some MCUs will have this phenomenon in a few minutes, and some in a few hours.A small number of MCUs can work properly without this problem. This problem can also occur when abnormal MCUs are switched to normal circuit boards. Normal MCUs have never had this problem.

If an exception occurs, the program is waiting for UCRxIFG to be set all the time, and UCTXIFG is not set. Normally, when waiting for the UCRxIFG flag, UCTXIFG  flag will be set.Why UCTXIFG is not set.

Sorry, I mis-read your symptom the first time. What you actually said was that both RXIFG and TXIFG were 0. This says that the SPI clock has stopped.

Since it's not so easy to (accidentally) stop SMCLK on the FR5, the other Usual Suspect is something about STE. It's supposed to be ignored in 3-wire (UCMODE=0) mode, but all the same: How is UCSTEM set? How do you have P7.3 configured? If a false master-conflict occurred, you should see UCFE set.

More generally, do the other UCB2 registers look reasonable? (Spot-check against accidental overwrite.)

The other UCB2 registers look reasonable.When an exception occurs, the UCB2 register is the same as the initial configuration and is not rewritten.

I don't seem to have told you about the system clock.

The system clock configuration is as follows:

       ACLK is sourced by  LFXTCLK.The clock of LFXTCLK is 32768-Hz.

       MCLK is Sourced by DCOCLK.The clock of DCOCLK is configured to be 8MHz.

      SMCLK is Sourced by HFXTCLK.The clock of HFXTCLK is 8MHz.

SPI CLK is Sourced by SMCLK.In this configuration, it is easy to see that RXFLAG is not set and very frequently.

The clock source of MCLK was changed to HFXTCLK.The symptoms described above do not appear again.Why is this normal?Does the SPI clock and MCLK asynchrony cause this symptom（RXFlag is not set）?

Well, there is Erratum USCI45 which talks about "clock stretching" with UCxCLK asynchronous to MCLK [Ref Errata Sheet (SLAZ681M) p. 11]. It uses the word "significantly", though it claims the "operation completes as expected" (not-so-much Quantified). The workaround is effectively "Don't Do That".

More generally, I suspect you're into only partially-charted territory. I suspect most applications use a common source for MCLK and SMCLK. Outside of noting "Hey, I can do that?" I've never actually built a system with SMCLK asynchronous to MCLK. Over the decades I've encountered a number of clock-boundary bugs, and they're notoriously difficult to find/prevent.

At this point, I don't think I have the equipment to do much. Maybe the Verilog Folk can help?

Hi,

we're looking into, whether the asynchronous clocking could be the root cause of the lost flag. In any case operating MCLK and SMCLK at the same nominal frequency but different clock source, which basically causes a more or less slow sweep of the clock edges over each other is definitely the most critical thing one can do, in terms of risking running into some clocking issues.

As it is nominally the same frequency, may I ask for the reason, why you're trying to operate the device like that?

Best regards

Peter

Thanks, Peter. I hope you'll be able to publish any findings. (Now I'm curious.)