This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TRF7970A: Linux Driver Problem TRF7970A_RSSI_OSC_STATUS register (0x0F) read as 0xFF

Part Number: TRF7970A

Hi,

We were having an issue with some of the custom boards that we use TRF7970A and opened a thread in this link before: 

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1034297/trf7970a-irq-does-not-occur/3842614

By debuggin the driver code at Linux side, we've figure out where the error occurs at the code:

 *It reads TR7970A_RSSI_OSC_STATUS and masks 2:0 bits of it to determine is_rf_field is true or false. 

In our situation, TR7970A_RSSI_OSC_STATUS is read as 0xFF and first three bit of it results in *is_rf_field = true which causes the problem at 1309 line of the driver code which returns -EBUSY.

In final we were able to solve this issue by removing the read of:

ret = trf7970a_read(trf, TRF7970A_RSSI_OSC_STATUS, &rssi);

And forcing *is_rf_field = false in any case.

Now, we can successfully read tags without any problem. Do you have an idea about why we're getting 0xFF from the read of TRF7970A_RSSI_OSC_STATUS register and how to fix it? We're not sure about removing this lines from the driver, will it cause any fault in our system in the future?

By the way, is this errata relevant for this issue, do we need to modify the driver code according to this errata and how?

  • Hi Utku,

    the must be something wrong with the read of the RSSI Levels and Oscillator Status Register (0x0F). A value of 0xFF should never occur. At least bit 7 will read always '0'. I would also not expect all RSSI values at '1'. I have checked with my reader (no Linux driver) and I read 0x40 from this register which is ok because it shows the oscillator is stable.

    What you have referred to in the errata does not apply to this issue. 

    You should try to fix the read problem of this register. I would not recommend to remove the register read, because from my understanding, this is implemented to check if a field from another reader is present before starting to send.

    Best Regards,

    Helfried

  • Hi Helfried,

    We have no idea why the register is being misread. Do you have? We were using TI's linux driver without changing it. We couldn't find a solution other than removing the register read. If you have any other suggestions, we can try.

  • Hi Utku,

    sounds strange. Because you have access to all other registers I can not think of a reason why the register at this address should behave different. That should not have anything to do that this a Linux driver. If the SPI register read and write works for the other registers why not for this one.

    Best Regards,

    Helfried

  • Hi Utku,

    I haven’t heard back from you for a while, so this tread is being closed. If you wish to continue the discussion, please post a reply with an update below (or create a new thread).

    Best Regards,
    Helfried