LP-MSPM0G3507: MFRC522 SPI ERROR

How do you tell that you have a problem with the SPI?

1) With SPI, every transmit byte is matched with a receive byte, whether you're interested in it or not. If you're not interested in the receive byte, you still need to read it and throw it away. In SPIReceive(), the byte you'll read will be the byte matched with the first (address) byte, not the second (response) byte, so you should read twice and keep the second. Similarly, in SPIsend() you should read twice and throw away both, so they won't be left over in the FIFO when you come back later.

2) What is the purpose of the DL_SPI_setControllerCommandDataModeConfig() call? Is CS3 connected to something? If not, it probably doesn't cause trouble (I haven't tried it) but it's probably unnecessary.

3) What is the MFRC522 "I2C" pin connected to? More generally: Are you using a commercial breakout board?

My product works with SPI. I leave the cs3 pin and other settings below. I have also communicated via SPI on another processor, but I am having difficulty integrating it into the TEXAS processor. The only areas I will change are SPI communication sending and receiving.

In the Debug section, I see that it is waiting in SPI BUSY.

I suggest you switch "Frame Format" to "Motorola 3-wire", since that's what you're using.  I don't see much about CSn in the TRM, but many MCUs are picky about the CS signals if you use 4-wire.

What is the CS3 pin connected to on the MFRC522? I suspect you don't want CDMODE.

I not connectoed cs3. Only use mfrc522 for SPI

I close thew CDM but not change anythink

unsigned char MFRC522_SPIreceive(unsigned char address_rcv)
{

SPI_receive_address = (((address_rcv << 1) & 0x7E) | 0x80); // Okuma işlemi için adres

MFRC_NSS_OFF;

//DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
DL_SPI_transmitData8(SPI_0_INST, SPI_receive_address);

while (DL_SPI_isBusy(SPI_0_INST))
;

//DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
DL_SPI_transmitData8(SPI_0_INST, DUMMY);

while (DL_SPI_isBusy(SPI_0_INST))
;

SPI_Received_data = DL_SPI_receiveData8(SPI_0_INST);

MFRC_NSS_ON;

return SPI_Received_data;
}

void MFRC522_SPIsend(unsigned char address_snd, unsigned char data_snd)
{

SPI_send_address = ((address_snd << 1) & 0x7E); // Yazma işlemi için adres
SPI_send_data = data_snd;

MFRC_NSS_OFF;

//DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
DL_SPI_transmitData8(SPI_0_INST, SPI_send_address);

while (DL_SPI_isBusy(SPI_0_INST))
;
//DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
DL_SPI_transmitData8(SPI_0_INST, SPI_send_data);

while (DL_SPI_isBusy(SPI_0_INST))
;

MFRC_NSS_ON;
}

for others MCUs sample ccode mfrc522

What is your symptom now? Are you still stuck in SPI_isBusy?

A) Your SPIreceive function will (still) return an incorrect byte (see (1) above).

B) Does MFRC_NSS_OFF set the /CS pin low?

C) Instead of waiting on SPI_isBusy, then calling SPI_receiveData8, you might try just calling DL_SPI_receiveDataBlocking8(), which will do the waiting for you.

[Edit: Fixed typo]

A) I don understand

B) YES , be LOW

C)Not change anythink 

unsigned char MFRC522_SPIreceive(unsigned char address_rcv)
{

  SPI_receive_address = (((address_rcv << 1) & 0x7E) | 0x80); // Okuma işlemi için adres

  MFRC_NSS_OFF;

  //DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
  DL_SPI_transmitData8(SPI_0_INST, SPI_receive_address);

  while (DL_SPI_isBusy(SPI_0_INST))
  ;

  //DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
  DL_SPI_transmitData8(SPI_0_INST, DUMMY);

  SPI_Received_data = DL_SPI_receiveDataBlocking8(SPI_0_INST);

  MFRC_NSS_ON;

  return SPI_Received_data;
}

void MFRC522_SPIsend(unsigned char address_snd, unsigned char data_snd)
{

  SPI_send_address = ((address_snd << 1) & 0x7E); // Yazma işlemi için adres
  SPI_send_data = data_snd;

  MFRC_NSS_OFF;

   //DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
  DL_SPI_transmitData8(SPI_0_INST, SPI_send_address);

  while (DL_SPI_isBusy(SPI_0_INST))
  ;
  //DL_SPI_setControllerCommandDataModeConfig(SPI_0_INST, 1); // 1 bayt komut gönderilecek
  DL_SPI_transmitData8(SPI_0_INST, SPI_send_data);

  while (DL_SPI_isBusy(SPI_0_INST))
  ;

  MFRC_NSS_ON;

}

void MFRC522_init(void)
{	
	
				
				MFRC_RST= 1;
			
				MFRC522_SPIsend(CommandReg, CC_RESETPHASE);
				MFRC522_SPIsend(TModeReg,        0x8D);
				MFRC522_SPIsend(TPrescalerReg,   0x3E);
				MFRC522_SPIsend(TReloadRegL,       30);
				MFRC522_SPIsend(TReloadRegH,        0);
				MFRC522_SPIsend(TxASKReg,   		 0x40);
				MFRC522_SPIsend(ModeReg,   			 0x3D);
			
				Antenna_ON();
		
}

I clicked solved by mistake, I SEND IT A 35 us SPI DATA I LEFT MY DATA SEND FREQUENCY BELOW

This pic. Other MCU pin hall grahp.WORKING 

This pic. TEXAS MCU pin hall grahp.NOT WORKING 

The analyzer trace doesn't show any sign of a halt in the transactions. Which operation hangs?

The fact that the clock is initially high is a bit disturbing, but at worst it only affects the first transaction. This is probably a separable question.

I send this data transfer almost every second

If you're sending this sequence every second (repeatedly), it sounds as though your "SPI hang" symptom has been fixed. What is your symptom now?

Or is this message from the analyzer the only failure you're seeing? Does it appear on every transaction sequence, or only the first-ever?

What (RC522) breakout board are you using? I don't recognize it from your photo.

Also, I have to ask: Why are you re-initializing the RC522 every second?