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: Proper wiring between BeagleBone Black and DLP-7970ABP

Part Number: TRF7970A
Other Parts Discussed in Thread: DLP-7970ABP, , MSP430G2553

I'm trying to run the demo from app note SLOA210 (Rev B).  The precise hardware listed in the app note does not appear to be available any more.  I couldn't even find a schematic for the RF cape!  So that leaves me guessing at the proper connections between these boards.  I'm using DLP-7970ABP Rev 4.3 hardware.  Here's my current hookup:

Function AM335x Pin BBB location DLP location
SS enable gpio1_5 (V8) P8, pin 22 not currently used
EN gpio2_3 (T7) P8, pin 8 Pin 10
EN2 gpio2_4 (U6) P8, pin 10 not currently used
IRQ gpio0_31 (U17) P9, pin 13 Pin 18
sclk spi1_sclk (A13) P9, pin 31 Pin 7
miso spi1_d0 (B13) P9, pin 29 Pin 14
mosi spi1_d1 (D12) P9, pin 30 Pin 15
CS spi1_cs0 (C12) P9, pin 28 Pin 9
GND P9, pin 46 Pin 20
3.3V P9, pin 4 Pin 1

The documentation doesn’t explicitly state the way to do multiple measurements, so it’s possible I’m making an error (though I’ve tried multiple variations).  Here’s what I see at the console:

root@am335x-evm:~# neard

root@am335x-evm:~# test/test-adapter powered nfc0 on

root@am335x-evm:~# test/test-adapter poll nfc0 on Initiator

root@am335x-evm:~# test/test-tag list

root@am335x-evm:~# test/test-tag dump

So at this point I’ve made one attempt at reading the card.  Nothing came out.  My RFID card was laying on the DLP board the whole time.  If I try to initiate another read, here’s what I see:

root@am335x-evm:~# test/test-adapter poll nfc0 on Initiator

org.neard.Error.Failed: Device or resource busy

I need to reboot the entire board in order to attempt it again.

There’s a jumper on the board to select IRQ as being “1” or “2”.  It was populated on “2” initially so now I’ve tried “1”.  No change in behavior.

I suspect this isn't working because I don't have things wired up correctly.  Any inputs would be appreciated.

Best regards,
Brad

  • Hi Brad,

    I sent this over to our 3rd party partner who helped put this example together and initial feedback I got was to check the voltage settings in the DTS entries. It wouldn't be directly part of neard, but if there is a knob to control 3V vs 5V input (default will be 5V), then it would be there.

    He will likely join the discussion here within a day or two.
  • I'm using the dts exactly as it was provided in the app note.

    trf7970a@0 {
    compatible = "ti,trf7970a";
    reg = <0>;
    pinctrl-names = "default";
    pinctrl-0 = <&trf7970a_default>;
    spi-max-frequency = <2000000>;

    interrupt-parent = <&gpio0>;
    interrupts = <31 0>;
    ti,enable-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>,
    <&gpio2 4 GPIO_ACTIVE_HIGH>;

    vin-supply = <&trf7970atb_reg>;
    autosuspend-delay = <30000>;
    irq-status-read-quirk;
    en2-rf-quirk;
    status = "okay";
    };

    Can you please suggest more specifically what to change? I don't see any other knobs... This is the documentation for this devicetree configuration:

    Required properties:
    - compatible: Should be "ti,trf7970a".
    - spi-max-frequency: Maximum SPI frequency (<= 2000000).
    - interrupt-parent: phandle of parent interrupt handler.
    - interrupts: A single interrupt specifier.
    - ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
    TRF7970A. EN2 is optional.
    - vin-supply: Regulator for supply voltage to VIN pin

    Optional SoC Specific Properties:
    - pinctrl-names: Contains only one value - "default".
    - pintctrl-0: Specifies the pin control groups used for this controller.
    - autosuspend-delay: Specify autosuspend delay in milliseconds.
    - irq-status-read-quirk: Specify that the trf7970a being used has the
    "IRQ Status Read" erratum.
    - en2-rf-quirk: Specify that the trf7970a being used has the "EN2 RF"
    erratum.
    - vdd-io-supply: Regulator specifying voltage for vdd-io
    - clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz

    Example (for ARM-based BeagleBone with TRF7970A on SPI1):

    &spi1 {
    status = "okay";

    nfc@0 {
    compatible = "ti,trf7970a";
    reg = <0>;
    pinctrl-names = "default";
    pinctrl-0 = <&trf7970a_default>;
    spi-max-frequency = <2000000>;
    interrupt-parent = <&gpio2>;
    interrupts = <14 0>;
    ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>,
    <&gpio2 5 GPIO_ACTIVE_HIGH>;
    vin-supply = <&ldo3_reg>;
    vdd-io-supply = <&ldo2_reg>;
    autosuspend-delay = <30000>;
    irq-status-read-quirk;
    en2-rf-quirk;
    clock-frequency = <27120000>;
    status = "okay";
    };
    };

    Brad
  • Hi Brad.

    Are you using TI's SDK?  If so, which version?  If not, then what kernel version are you running?  The most important thing I need to know is exactly what version of the trf79790a driver you have (and neard too).

  • I'm trying to precisely follow the app note SLOA210 (Rev B).  That entails TI Linux SD 3.03 plus some other repositories it had me clone.  According to the ChangeLog file that's in my neard repo, it looks like I have ver 0.16.  The trf7970a driver is integrated into the Linux kernel right?

    Here's what I see in the git history for that driver:

    user@cfasvr2:~/ti-processor-sdk-linux-am335x-evm-03.03.00.04/board-support/linux-4.4.41+gitAUTOINC+f9f6f0db2d-gf9f6f0db2d$ git log --oneline drivers/nfc/trf7970a.c
    eb4605f Revert "NFC: trf7970a: Handle extra byte in response to Type 5 RMB commands"
    8709861 NFC: trf7970a: fix check of clock frequencies, use && instead of ||
    dd68fba NFC: trf7970a: Clean up coding style issues
    0a0f857 NFC: trf7970a: Convert to descriptor based GPIO interface
    5d1274a NFC: trf7970a: Remove support for 'vin-voltage-override' DT property
    6fa4697 NFC: trf7970a: Remove useless comment
    4f6f21c NFC: trf7970a: Only check 'en2-rf-quirk' if EN2 is specified
    f3fc7bd NFC: trf7970a: Fix inaccurate comment in trf7970a_probe()
    47d6818 NFC: trf7970a: Don't de-assert EN2 unless it was asserted
    50b656c NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
    b8023c5 NFC: trf7970a: add device tree option for 27MHz clock
    3267398 NFC: Make EN2 pin optional in the TRF7970A driver
    76baa16 NFC: trf7970a: add TI recommended write of zero to Register 0x18
    501bf8a NFC: trf7970a: use to_spi_device
    75f5db39 Merge tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
    3821a06 spi: Drop owner assignment from spi_drivers
    3c39c1a NFC: trf7970a: Add OF match table
    aaee24a NFC: trf7970a: Add NULL check to clear up smatch warning

  • I've hooked up a logic analyzer to better understand what's happening.  Initially I put it into oscilloscope mode.  I could see the voltage levels were the expected 3.3V levels.  However, the signals themselves looked horrible so I slowed the interface way down to 100 kHz so that things look nice and clean.

    Then I switched to the logic analyzer mode and switched on the SPI analyzer.  In all the transfers that have occurred the MISO bit has been zero the entire time.  So it seems to me that something major is wrong with the TRF device, e.g. like it is still in reset or something.

    Here's an arbitrary screenshot just to give you an idea:

  • Hello Brad,

    Is Data CLK is at 100kHz? You can't do that, minimum specification is 2 MHz for Data CLK. Saleaer should have no issue sampling a 2 MHz SPI clock. I can review full logic files if needed, Saleae is my go-to for debug.
  • Also should comment Saleae o-scope isn't good for digital signals to check for clean signals, you need to use a bench o-scope for that. Saleae o-scope is better for sub MHz signals.
  • Ok, I switched back to 2 MHz:

    I still see the same issue -- the TRF only responds with zeros...  Suggestions?

  • Hi Brad.

    The document you're using is getting a little old now and there have been several updates to the trf7970a driver and to neard since. I recommend that you do one of two things: a) Move to the latest am335x SDK from TI; b) Move to a much more recent version of the community linux kernel.

    Now having said that, I'm way behind on providing ready-to-go versions so you can either: a) do it yourself; b) wait for me to make updates available for the latest SDK & community (*hopefully* this weekend).
  • Mark,

    My end goal is to have all of this working on SDK 5.00 (kernel 4.14). I wanted to verify my local hardware setup before I start the software migration. That was my intent in using PRECISELY what was prescribed in the app note (i.e. known good software). Even though it's old, my expectation was that it actually worked and would therefore serve as the best baseline for development.

    I suspect that I still have a hardware issue which is why I'm only seeing zeros on the MISO line. I'd really like to get that resolved using the known, good software first. Then once I know my hardware works I can migrate to the latest kernel and focus on fixing all the software issues.

    If I move to SDK 5.00 right now, then I'm going to be simultaneously debugging hardware issues and software issues which is very difficult.

    Brad
  • And just to make sure - you are using a BeagleBone Black + RFCape + TRF7970ATB, correct?
  • Brad,

    I understand your dilemma and the instructions should still work but it is easy to get something wrong that can throw you off into the weeds. I'll work on SDK 5.0 and should have something for you by Monday. I will push it to a github repo so you can fetch, build, and test (on a BBB + RFCape + trf7979atb). If you have the same hardware, it should "Just Work(tm)" even though you're changing SDK versions.
  • Mark,

    No, that's not my setup...  That RF cape is no longer available.  In fact, not even the schematics are available!  So that leaves me guessing as to what signals connect to what...  I've got a BeagleBone Black being wired over to a DLP-7970ABP Rev 4.3 board.  Here's a picture:

  • Hi Mark,

    I think Brad as the DLP-7970ABP which doesn't have an easy adapter but the connections can be made by manually wiring the two boards together. In addition to the RF cape being near impossible to find nowadays, the TRF7970ATB is not available from TI either.

    Brad,

    I don't think hardware is the issue here... as long as the proper connections are made, there should be no issues, the BoosterPack is robust so just verifying the pinout and using semi-decent wires is more than enough. I've wired the BP to many other boards in that manner and never once had an issue.
  • Yeah, I should have noticed the DLP-79790ABP :). Anyway, that can explain a lot. In particular, the ATB board boosts the voltage from 3.3V to 5V so the regulator set up in the DTS need to account for that. I'll review the signal routing closer when I get on this for real.
  • Alternatively, the BP is 5V tolerant and I have sourced 5V into the VIN many times with plenty of success. Not sure if the BB Black has a 5V output pin though.
  • Ralph,

    If I supply 5V (presumably on pin 1 instead of 3.3V), does that regulate down internal to the TRF? The BBB cannot tolerate 5V I/O and I'm afraid I'm going to damage it by supplying 5V to the DLP board.

    Brad
  • The BBB's GPIOs are 3.3V.
  • Hello Brad,

    The DLP-7970ABP has VDD_I/O tied to VDD_X which will regulate down to 3.4V to 2.7V depending on Regulator control settings. This is what occurs on the TRF7970ATB which was previous used. It will be fine for the BBB GPIO though you'll need to get 5V from another source than the BBB.
  • Ralph,

    Is there an issue using P9 pin 6 from the BBB? That's a 5V pin. The BBB is powered by a 5V supply, so connecting 5V to the DLP board is an easy change. Should I go ahead and try that?

    Brad
  • Hi Brad,

    That'd work, I had misinterpreted Mark's comment about 3.3V GPIO to think the whole board didn't have a 5V rail but now I remember that yes it does. I would recommend using the BBB 5V supply, keeps it simple with the common ground between boards.
  • Ok, I just tried it. I confirmed in the oscilloscope mode that the voltages were still 3.3V. It behaves the same. I still only get zeros on the MISO.
  • Can you save & attach (or email) a .logicdata file so I can review it? I might be able to identify something quickly that way. Should have all 4 SPI lines, IRQ, and since it is in question as well, EN to be safe too.
  • Thanks, Ralph.  Here it is (captured in Logic 1.2.18):

    20 MHz, 300 M Samples.zip

    I'm assuming it keeps all the labels, etc. for the various channels.  Just in case though, here's how it is setup:

    • 0 = CS
    • 1 = SCLK
    • 2 = MISO
    • 3 = MOSI
    • 4 = IRQ
    • 5 = EN

    Looks like EN transitions 0->1 before any SPI activity ever begins, and it stays there.  I don't see any activity on IRQ, but then again I don't find that all that surprising given that we can't seem to read any data from the device!

  • Hello Brad,

    Thanks, looking at the file it looks like the SPI mode settings are right for phase/polarity and yeah EN has time active before commands are issued.

    If the MISO pin is truly on the right place, then it would seem the TRF7970A oscillator is not starting up.

    Do you have an MSP430G2553 or F5529 LPad laying around? Or the MSP432 LPad? Can double check the DLP-7970ABP is still working with any of those by using example code...
  • And you really don't have slave select connected? If not, then I'm not surprised it doesn't work.
  • And I would pull EN2 down.
  • Mark Greer_ said:
    And you really don't have slave select connected? If not, then I'm not surprised it doesn't work.

    As I reread this, I realize I should have worded it differently.  I didn't mean to sound sarcastic here.  My apologies if it sounded that way.

  • Okay, so I took some time to actually read what you wrote. Your wiring looks correct but I can't find a schematic for that board to verify anything. I hope it pulls EN2 low and my slave select comment doesn't apply to the board you're using.

    A few notes:

    1) I noticed is that you mentioned using an RFID card. Be sure to use an *NFC* card as RFID cards will not work.

    2) [You likely are okay here but possibly you're using a rootfs with some old NFC/neard things laying around] Are you sure that you are using the DTS/DTB that you think you are (and pushing the boot switch button while powering on)? You can check the DTB manually by looking in /sys/firmware/devicetree/base. You can also run the dtc command to reconstruct the DTS (dtc -I fs -O dts /sys/firmware/devicetree/base > foo.dts and look in foo.txt) but you will have to build it yourself (clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git and build using 'make NO_PYTHON=1'). If you're using a Debian-based rootfs, you can install the 'device-tree-compiler' package.

    3) I verified that everything in the instructions you're following still work when using a BBB + RF Cape + TRF7970ATB so its likely a wiring/electrical issue or maybe a step was missed or messed up somehow.

    4) I've don't have a DLP-7970ABP but I've ordered one that should be here in a few days.
  • Brad Griffis said:

    If I try to initiate another read, here’s what I see:

    root@am335x-evm:~# test/test-adapter poll nfc0 on Initiator

    org.neard.Error.Failed: Device or resource busy

    I need to reboot the entire board in order to attempt it again.

    That's the correct thing for it to report.  Its busy because it is still polling waiting for an NFC tag to appear.  You don't have to reboot, you can simply run 'test/test-adapter poll nfc0 off Initiator' (note the 'off' vs. 'on' you used before).

    This make me wonder even more if you're using an RFID card instead of an NFC card.  If you are, what you're seeing is exactly what I would expect you to see - there is no NFC card in range to it keeps polling indefinitely (hence the busy when you poll a second time).  It will continue to poll until you stop it with the 'off' command (see above) or it detects an NFC card; an RFID card will not work.

  • Hi Mark,

    Just want to tag along a few comments here:

    RE: 1) that's a good point, and ultimately Brad you will need to use something other than your TI badge HOWEVER, if that was the only issue we'd see SPI communication so I don't think that is the sole problem. That Register 0x0F reports 0x00 means the oscillator isn't on, so either there is no SPI communication or the clip got put on the wrong line somehow.

    RE: Schematic & EN2, it is pulled low so no worries there. Also you can get a schematic from http://www.ti.com/tool/TIDM-NFC-RW

  • Mark/Ralph,

    Thanks for all the comments.  Regarding the oscillator, I'm not clear on what action I should be taking.  I don't see any kind of oscillator on the board, nor do I see any pins that sound remotely like a clock input.  I'm assuming the oscillator is internal to the DLP module in which case it should "just work" right?

    With respect to the NFC card, sorry, I didn't realize there was a distinction there!  Thanks for calling that out.  I'm trying to find a proper NFC device.  Is a Mobil Speedpass considered NFC?

    Thanks,
    Brad

  • PS. Yes, I'm quite certain I'm booting the correct file system and dtb. As I changed the SPI frequency in the dtb I could see it correspondingly on the logic analyzer. I also see the EN pin being properly driven by the associated GPIO.

    Also, I don't have any of the other MSP430 boards, etc. that Ralph mentioned.
  • Ralph Jacobi said:

    Hi Mark,

    Just want to tag along a few comments here:

    RE: 1) that's a good point, and ultimately Brad you will need to use something other than your TI badge HOWEVER, if that was the only issue we'd see SPI communication so I don't think that is the sole problem. That Register 0x0F reports 0x00 means the oscillator isn't on, so either there is no SPI communication or the clip got put on the wrong line somehow.

    RE: Schematic & EN2, it is pulled low so no worries there. Also you can get a schematic from http://www.ti.com/tool/TIDM-NFC-RW

    Hi Ralph.

    Yes, good point on the SPI communication.  Speaking of which, as far as I recall, the 7970a uses SPI Mode 1 (i.e., cpol=0, cpha=1 (see )) so be sure to change that setting in the Saleae.  I don't think the 7970 is configurable in that respect but If its is, then that may be part or all of the problem as the driver assumes SPI Mode 1.

    Re: schematic - thanks.  After a quick scan only - are IRQ SEL (J4) pins 1 & 2 shorted?

  • Okay, good - I was just checking. :)
  • Brad, I don't know if mobil speed pass tags are NFC or not. Is there anyone physically near you that may have an NFC tag? Look for any NFC tag type other than type 1 (so types 2, 3, 4a, 4b, and 5).

    Please check the IRQ SEL because that being incorrect and not having an NFC tag would cause what we're seeing.
  • Mark Greer_ said:
    Speaking of which, as far as I recall, the 7970a uses SPI Mode 1 (i.e., cpol=0, cpha=1)  I don't think the 7970 is configurable in that respect but If its is, then that may be part or all of the problem as the driver assumes SPI Mode 1.

    Interesting note.  Though along those lines, shouldn't the dts file specify spi-cpha as part of the SPI configuration?

  • Mark Greer_ said:
    Please check the IRQ SEL because that being incorrect and not having an NFC tag would cause what we're seeing.

    I've tried it both ways.  I currently have it mapped to IRQ1 which I think is the right/better option.

  • Probably but it isn't. My understanding at the time is that it wasn't an option so I hard-coded it in the driver. You are right, though, it probably should be specified in the DTS so I will make that change.
  • Brad Griffis said:

    Mark Greer_
    Please check the IRQ SEL because that being incorrect and not having an NFC tag would cause what we're seeing.

    I've tried it both ways.  I currently have it mapped to IRQ1 which I think is the right/better option.

    Okay. Well then, hmm...

    Are there any test points on the DLP board that you could tap into?

  • Mark Greer_ said:
    Probably but it isn't. My understanding at the time is that it wasn't an option so I hard-coded it in the driver. You are right, though, it probably should be specified in the DTS so I will make that change.

    Looking at the timings on the logic analyzer, I'd agree with you that it looks like the the AM335x SPI is using Mode 1 (which makes sense given your comment about hard-coding it).

  • I was looking at the initialization sequence and comparing with the TRF7970A data manual (Section 6.11 TRF7970A Initialization).  My observations are:

    1. Steps 1 and 2 are completed.  I see on the MOSI data of 0x83 and 0x80 being transmitted.
    2. It looks like Steps 3 is missed.  I don't see the 1ms delay.    After the 0x80 is sent there is only a 15us delay before the next transfer begins (0x0B, 0x01), which looks to correspond with Step 6.
    3. Step 4 seems to also be missing (reset FIFO).
    4. I see the SYS_CLK register being written, though it is a big further into the log (i.e. it is byte #7 to be transmitted on MOSI).  The subsequent byte (the data) is ZERO.  Is that expected?  Looking at the register, it looks like that disables the OSC.

  • Brad Griffis said:

    I was looking at the initialization sequence and comparing with the TRF7970A data manual (Section 6.11 TRF7970A Initialization).  My observations are:

    1. Steps 1 and 2 are completed.  I see on the MOSI data of 0x83 and 0x80 being transmitted.
    2. It looks like Steps 3 is missed.  I don't see the 1ms delay.    After the 0x80 is sent there is only a 15us delay before the next transfer begins (0x0B, 0x01), which looks to correspond with Step 6.
    3. Step 4 seems to also be missing (reset FIFO).
    4. I see the SYS_CLK register being written, though it is a big further into the log (i.e. it is byte #7 to be transmitted on MOSI).  The subsequent byte (the data) is ZERO.  Is that expected?  Looking at the register, it looks like that disables the OSC.

    This section is new (is there some way to be notified when there is a document update??).  However, I worked very closely with Josh Wyatt (614) and  at the time to get the init sequence correct and it has been working reliably ever since (until now, possibly).  If I recall correctly, it does what other TI products at the time did and I'm hesitant to change anything in this area without clear evidence that it matters and that it is correct by someone at TI that "knows".

    Is there a new revision of this part?  If so, them maybe the init sequence is different for the new one.

    Re: SYS_CLK reg - writing zero should okay as we don't use the SYS_CLK output (as far as I can tell from the schematic).

  • Trying again to get looped in.
  • Brad, something to try, if you're up to it:

    Enable CONFIG_DYNAMIC_DEBUG and rebuild the kernel & modules, etc. Using menuconfig (or your favorite config method) and go into 'Kernel hacking'/'printk and dmesg options' and enable 'Enable dynamic pritnk() support'.

    Add 'trf7970a.dyndbg=+pfl' to the cmdline when you boot (note I haven't tried these exact steps to you may need to tweak this). Capture all of the console output and attach it here. More info on dynamic debug is here: www.kernel.org/.../dynamic-debug-howto.html
  • Actually, don't bother with this until we figure out what's going on with the trf7970a.
  • Hey guys,

    Sorry for my silence for a bit, on business travel.

    I would simplify this down a whole lot more. Let's make sure you can read back a register correctly. 0x0F is a good one because when the chip runs, then the oscillator on bit will be 1. So you will always get a non 0x00 reply from that register.

    That the response there was 0x00 is my point of concern.

    The oscillator is part of the BoosterPack by the way.

    If you can get your hands on an MSP430 LaunchPad like one of the two I mentioned, that'd be a very quick way to make sure your BoosterPack hardware wise is fine. If you have a dead BP then it would make sense why none of this is working...

    Mark RE the startup sequence, your setup is fine. Our Datasheet has a stricter version but that is just because most customers don't use our software and so we have the most reliable way that works for other MCUs as well on there. There isn't a new chip version, but the DS got updated a lot to clarify properly written or ignored points including start-up sequence.

    There isn't a lot of rocket science to this though, if the SPI connections are fine, the right SPI mode is used (I checked the polarity and phase on the LSA capture that was one of my main goals with getting it), and EN is handled right (which it is), then I am suspicious of the BoosterPack as a whole given how old it is. Who knows what it's been through.
  • Sounds like a plan.  I should have a board arrive on Friday but I'm not sure how much time I'll have to look at it before I have to travel on Sunday.  Which reminds me that I will be travelling next week and almost certainly won't have time to respond.

  • Hi Brad (and Ralph).

    Sorry for the delay, I had some travel and then unexpectedly busy.

    I received a brand new DLP-7970ABP board (v4.5) and I initially had the same results you had.  I double-checked my wiring and noticed and I messed up.  Once I fixed it, it worked like a champ.  So you probably either have a wiring issue or a bad board.  Did you get a different board and some NFC tags?

    Mark

    --

  • Hello Mark,

    Last I heard from Brad he was waiting on a new board and had some bandwidth challenges, so it's still open but I don't think he has tried with the new BoosterPack yet. Good to hear the setup works on your end, that's what I would expected based on the TRF7970A hardware!