CCS/RF430CL330H: Busy state

Hello Egor,

The BUSY status on the RF430CL330H indicates that a reader is in the area. It's meant to be there so data isn't loaded into the SRAM memory from the MCU controlling the RF430CL330H until the reader device has left the area. If you pull the phone from the tag, does the BUSY status clear?

Hello! Thanks for your reply.
When, I remove the phone the busy state is saved and the interrupts stop coming, the registers remain readable.

Sometimes also, there can be a situation when after the next operation of writing / reading the tag is read as empty.

Sorry, I probably chose the wrong forum thread. I need to re-create the post, or moderator can move it to the branch NFC/RFID? 

Hello Egor,

I moved the post to the NFC forum. Regarding the behavior described, it really sounds like the RF430CL330H RF_Lock errata item. I see in your code you have the errata included, and that it is called during the nfc_task_function API execution. Few questions for you though:

1) Is the nfc_task_function called only once, or is it on a schedule?
2) Are there any points when the RF430CL330H is reset via either hardware or software without calling the nfc_task_function?
3) Have you scoped the I2C lines to verify the errata is being correctly applied?

Hello, Ralph! Thank you very much for your reply.
Forgive me for not being able to respond right away.

1. Creating a task in the main funtion:
   

   int main()
   {
     /* Register Application callback to trap asserts raised in the Stack */
     RegisterAssertCback(AssertHandler);
   
     PIN_init(BoardGpioInitTable);
   
   #if !defined( POWER_SAVING )
     /* Set constraints for Standby, powerdown and idle mode */
     // PowerCC26XX_SB_DISALLOW may be redundant
     Power_setConstraint(PowerCC26XX_SB_DISALLOW);
     Power_setConstraint(PowerCC26XX_IDLE_PD_DISALLOW);
   #endif // POWER_SAVING | USE_FPGA
   
   #ifdef ICALL_JT
     /* Update User Configuration of the stack */
     user0Cfg.appServiceInfo->timerTickPeriod = Clock_tickPeriod;
     user0Cfg.appServiceInfo->timerMaxMillisecond  = ICall_getMaxMSecs();
   #endif  /* ICALL_JT */
   
     /* Initialize the RTOS Log formatting and output to UART in Idle thread.
      * Note: Define xdc_runtime_Log_DISABLE_ALL to remove all impact of Log.
      * Note: NULL as Params gives 115200,8,N,1 and Blocking mode */
     UART_init();
     UartLog_init(UART_open(Board_UART0, NULL));
   
     /* Initialize ICall module */
     ICall_init();
   
     /* Start tasks of external images - Priority 5 */
     ICall_createRemoteTasks();
   
     /* Kick off profile - Priority 3 */
     GAPRole_createTask();
     ProjectZero_createTask();
     /* enable interrupts and start SYS/BIOS */
   
     /* NFC */
     nfc_create_task();
   
     BIOS_start();
     return 0;
   }

   More nfc_task_function is not used anywhere.

2. I did not notice the hardware and software restart points (logs are output when the project is started, I can see if there was a restart).
3. In the function errata_fix I added reading registers:
   

   static void errata_fix(void)
   {
       //Please implement this fix as given in this block.  It is important that
       //no line be removed or changed.
       uint16_t version;
       uint16_t check_reg = 0;
   
       read_nfc_register(nfc_i2c_handle, VERSION_REG, (uint8_t *)&version, sizeof(version));
                                              // read the version register.  The fix changes based on what version of the
                                              // RF430 is being used.  Version C and D have the issue.  Next versions are
                                              // expected to have this issue corrected
                                              // Ver C = 0x0101, Ver D = 0x0201
       if (version == 0x0101 || version == 0x0201) {
           // the issue exists in these two versions
           write_nfc_register(nfc_i2c_handle, 0xFFE0, 0x004E);
           /* Check 0xFFE0 */
           read_nfc_register(nfc_i2c_handle, 0xFFE0, (uint8_t *)&check_reg, 2);
   
           write_nfc_register(nfc_i2c_handle, 0xFFFE, 0x0080);
           /* Check 0xFFFE */
           read_nfc_register(nfc_i2c_handle, 0xFFFE, (uint8_t *)&check_reg, 2);
   
           if (version == 0x0101) {
               // Ver C
               write_nfc_register(nfc_i2c_handle, 0x2a98, 0x0650);
           } else {
               // Ver D
               write_nfc_register(nfc_i2c_handle, 0x2a6e, 0x0650);
               /* Check 0x2a6e */
               read_nfc_register(nfc_i2c_handle, 0x2a6e, (uint8_t *)&check_reg, 2);
           }
           write_nfc_register(nfc_i2c_handle, 0x2814, 0);
           /* Check 0x2814 */
           read_nfc_register(nfc_i2c_handle, 0x2814, (uint8_t *)&check_reg, 2);
   
           write_nfc_register(nfc_i2c_handle, 0xFFE0, 0);
           /* Check 0xFFE0 */
           read_nfc_register(nfc_i2c_handle, 0xFFE0, (uint8_t *)&check_reg, 2);
   
       }
       //Upon exit of this block, the control register is set to 0x0
   }

   https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/667/read_5F00_errata_5F00_fix_2800_2-MHz_2C00_-10-M-Samples_2900_.7z
   
   Almost all the data corresponds to the recorded, only differs the state of the register 0xFFFE (write: 0x8000, read: 0x1AFD)

Hello Egor,

Thanks for the LSA capture, I read out the registers during the process for our example code as well and it looks like all errata is applied correctly. The result from the Register read you reported for 0xFFFE was identical for me, so that's fine.

Egor Bazyk said:

I did not notice the hardware and software restart points (logs are output when the project is started, I can see if there was a restart).

I don't know if I'd trust the software to say that isn't happening with 100% assurance. Can you check the RST line for the RF430CL330H and see if it is pulled low at any point, and if after that occurs, the issue you described happens? Given that the configuration is applied only once, if anything cause the device registers to reset such as the RST line being used to restart the device, then the errata would need to be reapplied. This would be a more objective manner to ascertain if the device was reset at all.

Also since you have a Saleae handy, when the issue occurs can you also scope out the INTO pin as well so I can track that behavior? So in total you want SDA, SCL, INTO, and RST on the capture.

Hello, Ralph!
Thanks very mutch for your reply.

Unfortunately, I can not yet provide you with the results of the capture of the I2C bus and the INTO and RST outputs (temporarily not available devices). In the near future I will try to provide you with the necessary data.