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.

TRF7960: Intermittent problem with 7960 receiver

Part Number: TRF7960

I have built a solution based on the 7960 - MSP430 combination. I am using the reference design for a power amplifier design and the TI supplied example code for the MSP4302370 & TRF7960 combination. I'm only really interested in ISO 15693 RFID transactions. The system is working well. However there are occasions when the receiver appears to "lock-up". I say this because I can continue to send commands from the host to the MSP430 and it responds. I also know that the 7960 is responding to the MSP430 requests across the 7960  parallel interface. I know this because I can see the forward link modulation of the reader as it tries to talk to an RFID credential. The part that seems to stop working is the receiver. Powering off and on again solves the problem.

I note this command is issued quite often during the inventory process:

command[0] = Reset;    // FIFO has to be reset before receiving
DirectCommand(command); // the next response

However this doesn't seem to reset the receiver. I note that the power on/off forces a transition through these commands:

TRFDisable;
delay_ms(5);
TRFEnable;
delay_ms(5);

My question is in relation to the impact the Reset  command has on the receiver and is it different to toggling the enable line ?

  • Hello Ian,

    The Reset command shown there is the FIFO Reset command.

    To reset the device and receivers, you need to use a Soft Init and Idle command sequentially. That would be Direct Commands 0x03, and 0x00.

    This is the recommended process to reset the device without power cycling if communication issues occur and should solve your lock up issue.
  • Ralph,

    Thanks for your reply. I'll insert these commands and give it a try.

    Regards,

    Ian

  • Ralph,

    In terms of the SoftInit & Idle commands, do they have an impact on VDD_X ? I use the +5 to +3.3V regulator from the 7960

     to the MSP430 and it seems like calling these commands impacts this regulator ? There doesn't seem to be much in the

     datasheet on these commands.

    Also, what would be the best way to determine if communication was functionally correct between the MSP430 & 7960,

     is there a version command or something similar ?

    Regards,

    Ian

  • Hello Ian,

    I think the impact you are seeing is that by using SOFT INIT, it is resetting Register 0x00 and Register 0x0B. So this means that the system will temporarily assume to be operating at 3.3V and not 5V because Bit 0 of Register 0x00 is cleared.

    The impact on VDD_X is that this would drop the voltage from 3.4V to possibly down to 2.7V at lowest. That voltage range should be just fine for any MSP430 device though as it is far above the BOR levels.

    The best way to check if communication is correct would be read a register you know the value of. A common check is to read Register 0x0F (RSSI Levels and Oscillator Status Register) to see if B6 for Crystal Oscillator Stable is set.

  • Ralph,

    That's a great help. Your understanding of the problem is correct, in the previous message I should have put health/status check rather

     than a version command (ie. something to check if all is well on the 7960 or whether it needed the Soft Init command to be sent.) From your

     response it seems like a read of the RSSI & Oscillator status would be the way to do this)

    Regards,

    Ian

  • Ralph,

    I think the lock up problem seen in the 7960 (ISO15693 receives) persists even when these commands are issued

    command = SoftInit;

    DirectCommand(&command);

    command = Idle;

    DirectCommand(&command);

    delay_ms(5);

    This may help reset the comms between the MSP430 & 7960 but it doesn't seem to be the same as a POR. I think it

     is possible to get the 7960 receiver into a very odd state with ISO 15693 receives - a state that is not cleared through the

     SoftInit, Idle commands.

    The lock up issue that I am seeing is resolved by

    TRFDisable;

    delay_ms(5);

    TRFEnable;

    delay_ms(5);

    However this is very inconvenient because it would mean hardware changes on my board.

    Any other workarounds possible ?

    Regards,

    Ian

  • Hello Ian,

    If that isn't solving it and your diagnosis about the Receiver being locked up is accurate, this may be an issue introduced by the power amplifier. We don't support those on these forums, and we have pulled an older design from the web.

    Can you test if the device works as expected without the Power Amplifier included?

    Another possible idea - just spitballing right now - is to try using the Block Receiver direct command and wait some period of time, 10-50ms maybe? and then use the Enable Receiver command. Maybe that could 'un-clog' as the Soft Init/Idle does not necessarily do that (though it will turn the TX off if the RF output was on).
  • Ralph,

    Thanks for the time taken in responding to my posts. I can confirm that the EnableReceiver/BlockReceiver with a delay doesn't solve the problem. However, I know what does and it is to toggle the TRFEnable pin. This clears the problem so I'll just bite the bullet and implement the hardware change.

    I'll close this one off now.

    Regards,

    Ian