STM32F427 CAN Remote Request

john239955_st · ‎2015-06-22

Posted on June 22, 2015 at 14:48

I am not sure if I am in the right Forum for this problem but have seen a similar problem in another STMF4xx.

I am configuring CAN bus and have a CAN message with Data as 'Remote Request,

I have used Cube MX in uVision5, what ever I do does not clear the Remote Request.

I have re-compiled in CooCox using Cube and this works fine .. so my hardware is OK.

I have used HAL_CAN_DeInit(xxx); with no effect.

Any help would be grateful.

Thanks John W

#can-rtr

jpeacock · ‎2015-06-22

Posted on June 22, 2015 at 19:48

By ''Remote Request'' I assume you mean a message with the RTR bit set in the identifier. The reception of this type of message means your network stack has received a request from a remote node to send a message (with data) that corresponds to the rest of the identifier, excluding the RTR bit.

First thing: an incoming message with RTR, the ''remote request'', does not have data since it is only a read request for remote data. The message should only have an identifier, zero data length. If data is present you have a problem with CAN software on the remote node generating the message.

Assuming your local node filtering matches the request, you reply with the same identifier but the RTR bit must be reset. The reply can contain data.

Clearing an RTR request is entirely a matter of the software protocol you are using. If you receive continuous RTR messages that's most likely caused by an improper response that doesn't meet what the originating node expects, so it retries.

For most protocols the RTR is only used when a remote node has to request data sooner than the periodic broadcast that usually provides the information. If the requested data is rarely used a remote node may be sending the RTR to force an early broadcast for the corresponding message. You might see this in a configuration phase where a node newly connected to a network has to ask for some specific object immediately, rather than waiting for the periodic message.

Jack Peacock

john239955_st · ‎2015-06-23

Posted on June 23, 2015 at 11:27

Thanks Jack,

My hardware is a STM32F427 connected direct to a Peak PCAN View.

I have a 5mSec loop with the following basic test code:-

do {

hcan1.pTxMsg->StdId = 0x22;

hcan1.pTxMsg->RTR = CAN_RTR_DATA;

hcan1.pTxMsg->IDE = CAN_ID_STD;

hcan1.pTxMsg->DLC = 0x08;

hcan1.pTxMsg->Data[0] = 0x11;

hcan1.pTxMsg->Data[1] = 0x22;

hcan1.pTxMsg->Data[2] = 0x33;

hcan1.pTxMsg->Data[3] = 0x44;

hcan1.pTxMsg->Data[4] = 0x55;

hcan1.pTxMsg->Data[5] = 0x66;

hcan1.pTxMsg->Data[6] = 0x77;

hcan1.pTxMsg->Data[7] = 0x88;

HAL_CAN_Transmit(hcan1, 1000);

delayMs(5);

}while(1);

This works OK using CooCox IDE but not in CubeMX/uVision5.

In CooCox if I change ->RTR to CAN_RTR_REMOTE then PCAN reads an ID of 0x22 a DLC of 8 with 'Remote Request' in the Data.

If I use CubeMx/uV5 ID is 0x240 and DLC is 4 with data as 'Remote request' which appears scrambled, changing RTR back to CAN_RTR_DATA has no effect.

I have compared some of the main code in Init files and HAL_CAN_Transmit with no apparent differences.

The clocks appear to be OK on an Oscilloscope, if I change Data Rate PCAN goes Bus Heavy.

I would appreciate any thoughts.

KR John W.

jpeacock · ‎2015-06-23

Posted on June 23, 2015 at 14:10

I use the standard library and Eclipse/GCC, no HAL or CooCox. From your description it sounds like a bit definition may be wrong. The RTR bit should not be set if you send data.

Check your message before you send it, see what the identifier looks like. I suspect it's a problem mixing definition headers in different environments. RTR should never be set if you send data,

Jack Peacock

john239955_st · ‎2015-06-25

Posted on June 25, 2015 at 14:46

Thanks Jack,

You are quite right the RTR bit is set.

My Tx array appears not to be intialising.

In Debug I have manually set the the ID and Data Registers and enabled the TXRQ bit this sends a message to my PCAN View OK.

Prior to the Tx Send I have put the following:-

hcan->Instance->TxMailBox->[transmitmailbox].TDLR = 0x12345678;

Debug does not show this value in the TDLR register.

I have check the CAN1/CAN2 BASE Address and all seems OK.

Any thoughts would help.

KR John W