Understanding the value of LLCE FIFO fixed mask

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Understanding the value of LLCE FIFO fixed mask

ソリューションへジャンプ
2,129件の閲覧回数
Mohamed_Abdelalim
Contributor I

Hello, 

I am working on a custom firmware for the LLCE and I have the access to the FDK and relevant documentation.

My question is about the LLCE_CAN_CONFIG_FIFO_FIXED_MASK_U32 which, in the delivered NXP firmware, is set to 0x0007_FFFF. The documentation doesnt specify how it came to this particular value, it mentions the FMR0 register, which is only of width 0x1FFF, so I am not sure whats the relation here.  

It's also confusing to me, why the mentioned mask is used when popping an entry from FIFO as u32 as the pushed entry was of type u16. why not just use a 0x0000_FFFF mask? I know it would yield the same result, but I am wondering if I am missing a point there that would be a difficult bug to resolve later on. 

I would appreciate your explanation.

Thank you in advance. 

 

タグ(2)
0 件の賞賛
返信
1 解決策
2,115件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Taking your point, it is true that this definition is used to extract u16 ID's, meaning that the 0xFFFF value you are mentioning should yield the same result. Yet, there is a condition in which this will not be true, this will be line 2279 on Can_Llce.c:

u32TxMbDescIdx = u32TxMbDescIdx & LLCE_CAN_CONFIG_FIFO_FIXED_MASK_U32;

If the mask is changed, this line could result differently. Still, the next line (2282) casts this result into a u16. This seems to be a more of a future-proof in case the "FrameIdx" variable changes to a u32 variable or could be that the "FrameIdx" was a u32 and changed to u16 in the process.

Still, I do not see any problem on leaving that definition as it is, at this point in time.

Regarding the FMR, I cannot find any situation in which it is used, so seems to be that "LLCE_CAN_CONFIG_FIFO_FIXED_MASK_U32" it is not related to the FMR register (at first glance).

Please, let us know if this information was helpful or not.

元の投稿で解決策を見る

2 返答(返信)
2,116件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Taking your point, it is true that this definition is used to extract u16 ID's, meaning that the 0xFFFF value you are mentioning should yield the same result. Yet, there is a condition in which this will not be true, this will be line 2279 on Can_Llce.c:

u32TxMbDescIdx = u32TxMbDescIdx & LLCE_CAN_CONFIG_FIFO_FIXED_MASK_U32;

If the mask is changed, this line could result differently. Still, the next line (2282) casts this result into a u16. This seems to be a more of a future-proof in case the "FrameIdx" variable changes to a u32 variable or could be that the "FrameIdx" was a u32 and changed to u16 in the process.

Still, I do not see any problem on leaving that definition as it is, at this point in time.

Regarding the FMR, I cannot find any situation in which it is used, so seems to be that "LLCE_CAN_CONFIG_FIFO_FIXED_MASK_U32" it is not related to the FMR register (at first glance).

Please, let us know if this information was helpful or not.

2,108件の閲覧回数
Mohamed_Abdelalim
Contributor I
Thanks a lot for the prompt and informative reply, I really appreciate it.
0 件の賞賛
返信