Just reporting a minor bug in HAL_FDCAN_GetProtocolStatus function.

XPach.2 · ‎2022-11-16

This line:

ProtocolStatus->Activity = (StatusReg & FDCAN_PSR_ACT);

I think it should be:

ProtocolStatus->Activity = ((StatusReg & FDCAN_PSR_ACT) >> FDCAN_PSR_ACT_Pos);

I'd appreciate if ST can confirm this.

Karl Yamashita · ‎2022-11-16

I concur with you findings, in a sense. Activity status are 3 bits to the left and needs a mask of 2 bits.

So adding .FDCAN_PSR_ACT_Pos will shift the bits over to the correct position.

And so the 2 bits represent

but you can't use ST's defines as they are wrong. But would work if you didn't add FDCAN_PSR_ACT_Pos to shift the bits 3 over.

I'd rather ST redo their defines so 0, 1, 2 and 3 are used as it makes sense.

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.

KDJEM.1 · ‎2022-11-22

Hello @XP.1acheco and welcome to the Community :),

For my side it is not a bug.

The activity function there is no need to shift the 3 bits because the comparison is done on all bits.

Thanks for your contribution.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

XPach.2 · ‎2022-11-22

I'm not sure what comparison you mean. I had to left shift 3 positions to properly read the activity bits status.

KDJEM.1 · ‎2022-11-22

Hello @XP.1acheco,

Could you please provide more details concerning your problem?

Do you have any problem when you use the activity function without shift 3 positions?

Thank you.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Karl Yamashita · ‎2022-11-22

ST's defines 0x0, 0x8, 0x10, 0x18 are correct when comparing to activity state. If you use your own defines which are probably 0x1, 0x2 and 0x3, then the comparison doesn't work. 0x0 will work though.

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.