NFCRdLib bug found

massimomanca — Tue, 05 Sep 2017 12:11:17 GMT

At row 871 in phNfcLib.c I found a bug, this is my proposed solution:

#if 0 // [MM] Warning[Pe063]: shift count is too large C:\Users\mmanca\My Documents\Projects\NFC\NfcFrontendsTest\NFCLibNXP\comps\phNfcLib\src\phNfcLib.c 877
sak_atqa = (uint32_t)((gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aSak << 16U) |
(gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aAtqa[0] << 8U) |
(gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aAtqa[1]));
#else
sak_atqa = (uint32_t)(((uint32_t)(gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aSak) << 16UL) |
((uint32_t)(gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aAtqa[0]) << 8UL) |
(uint32_t)(gphNfcLib_Params.sDiscLoop.sTypeATargetInfo.aTypeA_I3P3[0].aAtqa[1]));
#endif

Re: NFCRdLib bug found

IvanRuiz — Fri, 08 Sep 2017 18:16:43 GMT

Hello, Massimo.

It is not a bug; the objective here is to cast the resulting value of sorting the three uint8_t values into a uint32_t variable so that they don’t overlap. Only to clarify, the shifting is not made in the uint8_t variable, the processor carries out this shifting and OR process of the three variables and stores the final ORed and shifted values in a memory location to finally be cast to the size of the sak_atqa variable.

The solution you suggested will use more processing resources to obtain the same result.

I hope this helps you to understand in a better way.

Have a great day!

Best regards,

Ivan.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

topic Re: NFCRdLib bug found in NFC

NFCRdLib bug found

Re: NFCRdLib bug found