FDCAN Normal mode in STM32G491KCU6

[ssuresh]

Hi STM Expert,

This query is a continuation of the below ticket

https://community.st.com/t5/stm32-mcus-products/no-activity-observed-in-tx-pin-of-fdcan-in-stm32g491kcu6/td-p/733712

Right now, we are testing the normal mode scenario where we have taken two STM32G491KCU6 MCUs and considered one as the Transmitter and one as the Receiver.

Attaching the sample code we used for transmitting part and receiving part.

Since we only have one STMLink, we cannot run both MCUs in debug mode. So the transmitter MCU is simply booted up and receiver end we are planning to run in debug mode so that we expect the Rx buffer to get filled and observe the same in Live Expressions tab.

 

Please let us know if this method is correct?

[mƎALLEm]

Hello,

You didn’t share the code and I didn’t understand your issue. Please elaborate.

[ssuresh]

Hi Expert,

Our requirement is to transmit some data over FDCAN from one MCU to another MCU which acts as receiver.

When we tested this using oscilloscope, both Tx and Rx ends shows activity, but we need to validate if the date send itself is received over IDE debug mode.

Query 1:

We have only one STMLink available for this, so only one MCU can be put to debug mode. Hence only one MCU code can be executed line by line. Will that create an issue?

Query 2:

Also, when one MCU is transmitting, after the tx buffer is full, when it trigger the Rx interrupt, how does the other MCU know its time to receive data in normal mode? 

 

Attaching both Rx and Tx sample codes below.

Ioc file is the same as old one.

 

 

[mƎALLEm]

Hello,

I didn't understand this statement:

---

@ssuresh wrote:

but we need to validate if the date send itself is received over IDE debug mode.

---

Which one you are executiing step by step? the Rx or the Tx? 

---

@ssuresh wrote:

Query 1:

We have only one STMLink available for this, so only one MCU can be put to debug mode. Hence only one MCU code can be executed line by line. Will that create an issue?

 

 Also I didn't understand that sentence:

---

@ssuresh wrote:

Query 2:

Also, when one MCU is transmitting, after the tx buffer is full, when it trigger the Rx interrupt, how does the other MCU know its time to receive data in normal mode? 

---

The MCU "knows" a data was received when a RX interrupt is fired. That's it.

[ssuresh]

[STM] but we need to validate if the date send itself is received over IDE debug mode.

[VVDN] As per the code we are sending 8 bytes of data from Tx side. This data is found to be received in Rx pin of other MCU while probing, but we want to see this in STM IDE itself and not while probing (similar to what we see in External Loopback mode, in Live Expressions tab). Is that possible?

 

[STM] Which one you are executiing step by step? the Rx or the Tx? 

[VVDN] Rx side

 

[STM] Also, when one MCU is transmitting, after the tx buffer is full, when it trigger the Rx interrupt, how does the other MCU know its time to receive data in normal mode? 

[VVDN] In external loopback mode, got this point. But in normal mode, since reception part is coming in another MCU, wanted to understand how the Tx MCU notifies the Rx MCU for reception (from the sample code) shared. How they are linked?

 

Can you please check if the code shared will work?

 

[mƎALLEm]

Why stepping from Rx side? not a good idea.

The code is OK but it's not related to the implementation but the manner you debug the communication.

You need to go step by step from Tx side not from Rx side.

In Rx side the data will be updated automatically in the callback:

 

void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ITs)
{
 if((RxFifo0ITs & FDCAN_IT_RX_FIFO0_NEW_MESSAGE) != RESET)
 {
 /* Retrieve Rx messages from RX FIFO0 */
 if (HAL_FDCAN_GetRxMessage(hfdcan, FDCAN_RX_FIFO0, &RxHeader, RxData) != HAL_OK)
 {
 Error_Handler();
 }
 }
}

 

 Therefore, in the live expression, you can see the data updated i.e. RxData buffer. That's it.

[mƎALLEm]

Ok I  got the point.

Need to debug from Rx side and from Tx side you can send the frames triggered by a user button for example using EXTI.

No need to put break points in Rx callback. The data will be seen as soon as the Tx frame is sent from the other node.

Hope it helps.

[ssuresh]

Hi Expert,

Can you please elaborate the testing method?

With the code I shared to you, I cannot see the data in the Rx_Data[] buffer in STM IDE.

Rx MCU is executed step by step in debug mode connected using STMLink.

Tx MCU is simply booted.

 

[mƎALLEm]

As I said you don't have to execute step by step from Rx side. Run the application from Rx side and check Rx_Data in the Live Expression. You need to see the data changing in LIVE as soon as you receive data from the sender. If you don't see it, so there is an issue with the CAN communication.

[ssuresh]

Hi Expert,

Let me explain the testing we did.

CASE 1:

Flashed MCU1 (Transmitter side) with FDCAN_Tx code. Booted the system and simply probed the Tx pin. Observed the data in Tx pin.

But the same activity was also there in Rx pin. Is this expected? There is no Rx activity related code in FDCAN_Tx code.

 

CASE 2:

Flashed MCU2 (Receiver side) with FDCAN_Rx code.

 

CASE 3:

Connected MCU1 and MCU2 for testing FDCAN Normal mode.

Powered the MCU2 first which is the receiver. MCU2 was booted up in Debug mode.

Powered the MCU1 which is the transmitter. 

Then executed the application in Rx side (not in step by step mode, as per your suggestion). In the Live expressions, got an error for RxData side as shown below

Thus it seems like there is no data coming to the RxData buffer which is why it is throwing the error "failed to evaluate expression". Cannot understand why the callback function is not invoked in Rx side.

Is it related to the sample code we use? 

Can you please guide us on this?

[ssuresh]

Adding a new observation.

Once we run the application in Rx side, the activity in Tx side got lost (on probing on MCU1 Tx pin).

This might be the reason the callback is not getting called and RxData is not reading anything.

 

Can you give us a hint on why the activity on MCU1 Tx pin is lost when MCU2 starts to receive?