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: TRF7970A Initialization Sequence via F28388D ControlCard

Part Number: TRF7970A

Hello,

I'm integrating the TRF7970A chip using the Boosterpack sold by DLP Designs. I've used an oscilloscope to verify that commands are sent to the device properly, but I'm running into issues probably related to initialization. Post initialization, whenever I attempt transmitting commands or addresses for register operations I observe the following behavior on the oscilloscope (apologies for the hand sketch, this is only a representation):

I believe I initialized the NFC module properly by following the procedure in the data sheet on page 49. The following functions initialize the NFC module:

void initializeNfcModule(void)
{
         SpiTimerActive = false;

setSpiSlaveSelectHigh();

// Four millisecond delay between bringing SS high and then EN high per TRF7970A Datasheet
DEVICE_DELAY_US(4000);

// Set TRF Enable Pin (EN) High
setEnHigh();

// Wait until TRD system clock starts
DEVICE_DELAY_US(5000);

         // TODO: Set up TRF initial settings
         TRF7970A_initialSettings();
         TRF7970A_setTrfPowerSetting(TRF7970A_3V_FULL_POWER);
}

// Initialize the TRF7970A using commands
void TRF7970A_initialSettings(void)
{
         g_ui8CollisionPosition = 0;
         g_ui8FifoOffset = 0;
         g_ui8FifoRxLength = 0;

g_sTrfStatus = TRF_IDLE;
g_eTrfGeneralSettings.eTrfPowerSetting = TRF7970A_3V_FULL_POWER;
g_eTrfGeneralSettings.bRfFieldOn = false;
g_eTrfGeneralSettings.ui8IsoControl = 0x02; // TRF7970A Default

g_ui8IrqFlag = 0x00;
g_ui8TimeoutFlag = 0x00;

// Send out SOFT_INIT + IDLE initial sequence to soft reset
TRF7970A_sendDirectCommand(TRF7970A_SOFT_INIT_CMD);
DEVICE_DELAY_US(1000);
TRF7970A_sendDirectCommand(TRF7970A_IDLE_CMD);

// Delay to ensure soft reset is processed
DEVICE_DELAY_US(1000);

g_eTrfGeneralSettings.ui8IsoControl = 0x21;

TRF7970A_resetFIFO(); // Reset the FIFO

// Configure the system for ISO14443A cards

TRF7970A_writeRegister(TRF7970A_ISO_CONTROL, 0x08);  // For Iso14443a cards

TRF7970A_writeRegister(TRF7970A_MODULATOR_CONTROL, 0x01); // ASK 100%, no SYS_CLK output

TRF7970A_writeRegister(TRF7970A_REGULATOR_CONTROL, 0x01);

         TRF7970A_writeRegister(TRF7970A_NFC_TARGET_LEVEL, 0x00); // For TRF7970A Errata
}

Unfortunately all data extracted from the MISO line during communication always returns 0xFF because the MISO line is always high (see above picture).

My question: is there anything wrong with my initialization sequence? I cant see any issues.

-Charlie

  • Hello Charles,

    Can you post oscilloscope shots?

    I would recommend trying to keep this simple and do the following:

    Raise the EN and SS lines per the timings that you have identified from the Datasheet, and then read Register 0x0F RSSI Levels and Oscillator Status Register to see if the Crystal Stable bit is equal to 1. That is Bit 6 so the value read should be 0x40.

    This is the best way to test the SPI interface without getting into the rest of device initialization.

    With o-scope you should also check for the SPI clock frequency.

  • Ralph,

    I can't post oscilloscope images just yet but I'll try to get them soon.

    I've initialized the module per the data sheet. But it still looks like the chip is brought up incorrectly.

    As for what's happening, I can say for now that the MISO line is approximately 3V all the time. There's a small drop at the start of an SPI transmission, but everything is read on the MISO line as high. So responses are always read back as 0xFF. Regardless of what command I send.

    I've verified that the commands sent on MOSI are correct. But I just can't get a valid response from the module.

    The SPI clock frequency comes back as 2MHz, as I configured in the code.

    -Charlie

  • Hello Charles,

    And you are using the BoosterPack right? Can you cross check the connections carefully? I hate asking that, but one time myself and another customer spent a week on here only to find he had put one of the SPI lines one pin wrong on the header when wiring the BP to some non-LaunchPad dev kit. :)

    Did you also check for the right polarity and phase for the clock? The device only works for one SPI mode which would be Mode 1 (Polarity = 0, Phase =1).