Pass-through mode: SRAM_RF_READY flag ambiguity

[gauravbanyal]

Hello,

I am using pass-through mode with NTAG I2C 2k version and communicating with a custom app on an android phone.

Pre-condition : FD_ON and FD_OFF are both set to 11b and passthrough mode is turned on by the uc host when the tag is detected (tag is externally powered). The direction is set to RF_TO_I2C.

1. The NFC side initiates the communication by writing 64bytes to the SRAM.
2. When the uc host sees SRAM_I2C_READY flag set, it does a read on the SRAM.
3. Next, the uc host writes 64 bytes to the SRAM
4. The uc Host reads the NS register and sees the value 0x29. => RF_LOCKED =1 and SRAM_RF_READY = 1.
5. When the FD_OFF event is received in the uc host, the Transfer direction is set to RF_TO_I2C.
6. The NFC app waits on the flag SRAM_RF_READY to become TRUE to do a read operation on the SRAM.

!!Quite often, the SRAM_RF_READY does not appear as set to TRUE.

The app has a timeout to wait for the SRAM_RF_READY to become TRUE. Quite often, it hits the timeout.
Strangely, even after the timeout, if the SRAM is read by the NFC app, it gets the data that was written by the I2C side.

Please help!!

[Kan_Li]

Hi Gaurav Banyal,

Have you turned the direction from RF_TO_I2C to I2C_TO_RF between step 2 and step 3? If yes, would you please check the SRAM_RF_READY flag status from the uc host side when this issue occur? I am thinking maybe this issue is related with your custom app on the android phone.

Hope that helps,
Have a great day,
Kan

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

[gauravbanyal]

Hello Kan,

Sorry for coming back this late on your response.

I checked from the uC side. I see that sometimes SRAM_RF_READY is not set to TRUE after the terminator block of the SRAM is written to from the I2C side. I understand that flipping this flag to 1 is the responsibility of the NTAG Passthrough communication arbitration function on the NTAG I2C plus chip. Therefore I need further help on what exactly should be checked from the custom android application side to get rid of this problem.

The application at the moment only just waits for SRAM_RF_READY to be set to 1 for doing a read and it never gets set to 1.

Thanks for your help,

Best regards,

Gaurav.

[Kan_Li]

Hi Gaurav,

I am sorry, but you haven't answer my question: Have you turned the direction from RF_TO_I2C to I2C_TO_RF between step 2 and step 3?  Would you please help to clarify?

Thanks for your patience!

Have a great day,
Kan

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

[gauravbanyal]

Hi Kan,

Sorry I missed to mention that. I am switching the direction to I2C_TO_RF before writing to the SRAM. Following is my API to write to the SRAM.

==============

void SendDataToNFCReader(uint8_t *buffer)
{
   if (NfcFieldPresent){
#if (DEBUG_PRINTS_SWITCH ==1)
      printBuffer("\r\nSRAM send buffer:", buffer, 64);
#endif
      if( invisible_ok != ntag_set_transfer_direction(I2C_TO_RF) ) {
         PRINTF("%s, %s[%d] ntag_set_transfer_direction failed!\r\n", __FILE__, __func__, __LINE__);
      }
      else if( invisible_ok != ntag_write_bytes(NTAG_MEM_ADDR_START_SRAM, buffer, NTAG_MEM_SRAM_SIZE) ) {
         PRINTF("%s, %s[%d] ntag_write_bytes failed!\r\n", __FILE__, __func__, __LINE__);
      }
#if (DEBUG_PRINTS_SWITCH ==1)
      uint8_t ns_reg;
      invisible_status_t status = ntag_read_session_register( NS_REG, &ns_reg );
      if( invisible_ok != status ) {
         PRINTF("%s, %s()[%d], ntag_read_session_register failed! NS_REG\r\n", __FILE__, __func__, __LINE__);
      }
      PRINTF("\r\n NS_REG = 0x%x" , ns_reg);
#endif
   }
}

==============

Best regards,

Gaurav Banyal.

[Kan_Li]

Hi Gaurav,

Thanks for the information! but referring to your code, I found the functions you called are different from what the lib provides, for example, you used ntag_set_transfer_direction() here, while the NTAG lib defines it as "BOOL NTAG_SetTransferDir(NTAG_HANDLE_T ntag, NTAG_TRANSFER_DIR_T dir)", did you modify the lib? Please kindly help to clarify.

Have a great day,
Kan

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

[gauravbanyal]

Hello Kan,

I took the code from here "SW3647\workspace_ntag_i2c_plus\NTAG_I2C_API\src\HAL_NTAG" and modified it to my needs. I think it will help you if you saw my code. Please refer to the attached files.

Best regards,

Gaurav.

[Kan_Li]

Hi Gaurav,

Thanks for the information! Referring to your code, looks like you ported this LPC project to KSDK project, but actually we have already provided the ported project in the latest ver 2.2 sdk, please kindly refer to the following for details.

so I think maybe that is a better starting point for your application.

To download the latest sdk, please refer to Welcome to MCUXpresso | MCUXpresso Config Tools 

Hope that helps,

Have a great day,
Kan

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

[gauravbanyal]

Hello Kan,

Thanks for your response.

I have never downloaded SDK for the KL02Z microcontroller as I am using an MKL03. I assume the SDK I2C driver for both chips will be different so I might need some adaptation anyway. I will do a review when I get a chance. Have you been able to spot something wrong with the files I sent you earlier?

Best regards,

Gaurav.

[Kan_Li]

Hi Gaurav,

I didn't find any wrong with the files you sent before, but it is recommended using the official lib for your application , because there is a ready demo for your reference, and you may speed up your development with that. I have also consulted with ksdk team, sdk 2.2 also supports kl03, though its BSP doesn't include NTAG I2C demo, but it is easy to port it from kl02 to kl03. Actually there is no big difference between them, and they both support I2C communication.

Have a great day,
Kan

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