Just reporting a minor bug in HAL_FDCAN_GetProtocolStatus function.

[XPach.2]

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]

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.

[KDJEM.1]

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

[XPach.2]

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

[KDJEM.1]

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

[Karl Yamashita]

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.