• State TI Thinks Resolved
  • Locked Locked
  • Replies 24 replies
  • Answers 1 answer
  • Subscribers 17 subscribers
  • Views 14003 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RF430FRL152H: UART commands for TRF7970A to query SensorHub project

Ken Ward
Intellectual 345 points
Part Number: RF430FRL152H
Other Parts Discussed in Thread: , TRF7970A, MSP-FET

Apologies if this topic has been covered before, didn't find it during searches.  Plan: PIC24F using UART comm to DLP2 module, RF to 152H then I2C to LIS3MDL magnetometer.  Have UART traffic captures from GUI app to 7970A EVM, I2C captures for the SHT21 and ISL29023 sensors.  CCS 6.2.0 for 152H code, MPLAB-X 3.30 for PIC code.

Using SensorHub example project, replaced Digital_Sensor1 I2C code with LIS3MDL X-axis I2C write/read code.  DS2 handles Y-axis, DS3 handles Z-axis.  Modified DigitalSensorInit() as required.  Thinking when 152H ROM calls each DigitalSensor1-3 in turn, will get results from X, Y, Z axes.

When the GUI app starts the SensorHub demo, there is UART traffic for each of the project sensors.  1st there's a 8-byte write to Block1, then a 8-bit write to Block2, finally an 8-bit write to Block0.  I understand the contents of those writes, as they relate to the SHT21 and ISL29023 sensors.  Looking for clues about what to write to the DLP2, to get it to trigger the 3 ROM calls to DS1-3.

Thanks for reading this post!

  • 0
    TI__Expert 7820 points
    To make the ROM interface with digital sensors, it is best to start out with the SensorHub project. It has the example for the initialize function and also the sampling functions that are called each time a digital sensor is scheduled to be sampled.
    Once you have this done these settings should be written over RF to start the sampling process for each digital sensor.

    Select each of the digital sensors in the Sensor Control Register (address 0xF86A). Set number of passes to be 1. Frequency settings are do-not-care with only one pass. These settings can only be written once.

    Then each time that the three sensors need to be sampled, set the Start bit and wait until they completed. Over RF that would probably mean polling the status register. It can be done more intelligently by determining how much time the sampling process takes to complete and then start the polling.

    The result will be stored in the logging memory section, which is 0xF8B0. Digital sensor 1,2,3 in that order.

    If you run into problems, you can run SensorHub demo using the RF430FRL152HEVM PC GUI ( www.ti.com/.../slac692 )
    It sets up the registers as I described them. You can check this for yourself by viewing each of the tabs. You can even test your digital sensors with the GUI as well and see the results. The GUI is tested to work with the TRF7970AEVM - not sure if you have one. It should also work with the DLP-RFID2 module.
  • 0 in reply to Alex K.
    Intellectual 345 points
    Thanks Alex for looking at this! Yes, started with the PC GUI app, a TRF7970A EVM, a RF430FRL152H EVM + SensorHub, running the SensorHub project. By watching the UART Rx/Tx on the 7970A, can see that when the GUI is running, there are 3 consecutive ISO write requests to Block 1, 2 then 0, followed by 152H I2C write/read traffic for the SHT21 temp, SHT21 humidity, ISL light sensor. Works fine, as expected.

    In the SensorHub project, replaced the DigitalSensor 1 I2C code with the LIS3MDL X-axis code, similarly with DigitalSensor 2/3 for Y/Z axes, updated the Initialize function.

    If I'm understanding your suggestion, I'd send this string to the DLP2, to start with:
    01 0B00 03 04 18 0221 F86A 07 0000 which is SOF, 000B=len, 03=ReaderType, 04=Entity, 18=ISO, 0221=write, F86A=address 07=select, EOF

    Do something similar to set the #of passes. I'd put these in my controller Init routine, so they're not called with every sample.

    Am I on the right track here?
  • 0 in reply to Ken Ward
    TI__Expert 7820 points

    No the string you propose would not work.

    Regarding the formatting of the commands, you can check this thread out, specifically the Sampling_Command_Sequences document.

    https://e2e.ti.com/support/wireless_connectivity/nfc_rfid/f/667/p/427665/1755155#1755155

    The address is not sent as 0xF86A or other.  Rather ISO/IEC 15693 addresses to memory using blocks.  Block 0 starts at FRAM address 0xF868.  Each block can have 4 or 8 bytes.  This block length is read and written with that amount of bytes.  RF430FRL152H support both 4 and 8 byte block modes. So if a 4 byte block tag is being read block 1 would start at 0xF86C.  This is documented more in this E2E post: https://e2e.ti.com/support/wireless_connectivity/nfc_rfid/f/667/p/592930/2179248#2179248

    In the TXT document I mentioned above, it describes the the write and reads are formatted.  However, it does not describe the full string, with the SOF , length - it only starts at 18 and on.  You do not need the full string if you use the TRF7970AEVM's PC GUI. 

    You can use the TRF7970AEVM's PC GUI and use the "Send" button on the Test tab - starting with 18 and onward. 

    If you are only using the three digital sensors, formatting and sending block 1 is all that is required to start the sampling process.

    Assuming that your EVM is configured in 8 byte block mode - which is what works with its GUI then I have prepared the following that you need to send.

        B> WRITE BLOCK 0 LAST: (after writing this will initiate the sampling process)
            8 Bytes:
                1 => 01 - Start bit is set, after this is written this starts the sampling process
                2 => xx - Status byte
                3 => 70 - Digital sensors 1,2 and 3 selected
                4 => 00 - Frequency register, this is do not care since only one sample or pass is done
                5 => 01 - Only one pass is needed
                6 => 01 - No averaging selected
                7 => 00 - No options selected
                8 => 00 - No option selected
                So together: 01 00 70 00 01 01 00 00
                Sending on Test tab:
                    180221000100700001010000

        C> Result:
            Since multiple sensors were selected with long conversion times, we will have to poll for status.
            To do this, we can read block 0 and wait until the status byte turns to 02.

            Reading block 0x00:
                    18022000 - enter in Test tab
                Response:
                    [0001<01>0F0001010040] - The second 01 indicates that a conversion is in progress (<> added)
                    [0000<02>0F0001010040] - When the sampling process is complete, the second byte will be a 02 (<> added)
            Reading block 0x09:
                    18022009 - enter in Test tab
                    Response: [001869185F9A02FFFF]
                0x00 - Read succeeded
                        Digital Sensor 1 measurement:       0x6918
                        Digital Sensor 2 measurement:       0x5F18
                        Digital Sensor 3 measurement:       0x029A

  • 0 in reply to Alex K.
    Intellectual 345 points

    Thanks for the clarifications, the pointers to other posts, the detailed description of register reads and writes.  Based on your suggestions, the registers in block 0 are getting setup correctly on my unprogrammed tags.  Reading/writing/reading through the Test tab on the GUI works, but obviously there's nothing in block 9 but FF's since the tag is not programmed yet.

    With CCS 6.2.0 and MSP-FET using the level-shifter out of the MSP-TS430L092 kit, my code based on the SensorHub example builds, the debugger connects to the target, with 668 code and 51 data bytes written.  It doesn't auto-run because there's no Main symbol, so start it running manually.

    Now my programmed tag doesn't respond to any commands from the GUI like Inventory, and the write to block 0 returns [] instead of [00].  My breakpoints in DigitalSensorMeasurement() and the MagnetometerMeasurement() are not being hit. 

    I'll keep working on this, thanks again for the help.

  • 0 in reply to Ken Ward
    Prodigy 100 points

    Try 180021000100700001010000 this instead of 180221000100700001010000 it will work

  • 0 in reply to Alex K.
    Prodigy 100 points
    What if I want to read ADC Sensors? I set

    3 => 70 - Digital sensors 1,2 and 3 selected to 3=> 07 - Analog Sensors

    But, I don't know which block gives the ADC sensor values.
  • 0 in reply to Parthiv Prajapati
    TI__Expert 7820 points

    Ken,

    Debugger access can be disabled after reset by the ROM code since the ROM will try to use the JTAG pins as GPIO.  This can be prevented by setting a virtual register called : JTAG Enable Password Register to 0x39 ( see section 7.23 in the RF430FRL15xH Firmware Users Guide).  This will only take effect after a reset.

    Also after programming it is best to disconnect the debugger and reset the device unless debug access is needed.

    No RF functionality after a reset may indicate that the driver table is not properly formatted.  If you need to, if you send a binary .txt file of your program I can take a look to see if this is the case.

  • 0 in reply to Parthiv Prajapati
    TI__Expert 7820 points
    Parthiv, if you are using the 8-byte block mode it is block 9.
  • 0 in reply to Parthiv Prajapati
    Intellectual 345 points

    Yes, I spotted that yesterday.  Working much better now.

    Using the TRF7970A EVM GUI app, once the Set Protocol is used, go to the Test tab for rest of commands.

    Sending 180021000100700001010000 returns [00] which indicates a successful Register Write.

    Reading Block 00 via 18002000 initially returned 01 from the Status Register, indicating Sampling In Progress.

    Repeated reads finally returned 02 from the Status Register, indicating Data Available In FRAM.

    Reading Block 9 via 18002009 showed my hard-coded string for each of the 3 Digital Sensors enabled.

    Next I'm working on the I2C code to query the LIS3MDL magnetometer on each axis.

    Thank you Alex!

  • 0 in reply to Alex K.
    Prodigy 100 points
    It means, the block 9 is for all sensors. Could you tell me where it's explained. I could not find block 9 in following document
    www.ti.com/.../slau603a.pdf
  • 0 in reply to Alex K.
    Intellectual 345 points
    Alex,

    Yes, after the the project builds and the Debug session is started, CCS indicates programming complete:

    MSP430: There were 280 (code) and 51 (data) bytes written to FLASH/FRAM. The expected RAM usage is 0 (uninitialized data + stack) bytes.
    MSP430: AutoRun: Target not run as the symbol "main" is not defined

    and waits for a Run command, at the Reset_ISR()

    This is when I halt then disconnect the debugger, then after reset my modified SensorHub example app responds to the GUI commands. Yay!

    However none of my breakpoints inside the app are being honored, after hitting the Run icon. I must be doing something else wrong. Any hints?

    Thank you.
  • 0 in reply to Ken Ward
    TI__Expert 7820 points
    So the difference between 1800 and 1802 is the latter is for high speed. I really do not know why your app is not communicating (i think this is what you mean). Make sure that you are using 02 as your flags in your app since this is the most accepted parameter.

    To make the TRF7970AEVM GUI work with the 1802 option, do the following procedure:
    1. Select for example read single block option.
    2. Select High Data Rate
    3. Click on Set Protocol
    4. Type in a block number as 00 for example
    5. Execute a read

    After a valid response, use the Test tab with 1802...
  • 0 in reply to Parthiv Prajapati
    TI__Expert 7820 points
    Parthiv, it is section 7.51 - Logging Memory Space

    The sensors are logged there in the order they were selected. If there is more than one number of passes then they cycle.

    If you use the RF430FRL152HEVM PC GUI, after selecting a few sensors, running the sampling process, in the View Sensor Data tab you can see the address the sample was stored and the corresponding sensor that it was taken from.

    Check the RF430FRL152HEVM Users Guide: ( www.ti.com/.../slau607 ) for more information on this.

    Parthiv, for clarity and in the future, if you have a question please start your own thread.
  • 0 in reply to Alex K.
    Intellectual 345 points
    Yes, 1802 works if I check the High Data Rate box before setting the protocol. I'll continue using the High Data Rate setting.
  • 0 in reply to Alex K.
    Prodigy 100 points

    Thank you Alex for clarification. I apologies, for adding my question in wrong thread.

  • 0 in reply to Ken Ward
    Intellectual 345 points

    Looking for a hint on how to get the debugger to run, so I can debug the I2C code in the SensorHub example project.  No breakpoints are getting hit, even for very basic operations.  Is the lack of a "main" symbol an issue?  Could it be a compiler version or optimization level?  I'm using 15.12.3.LTS in place of 4.4.5

    Am successfully using the MSP-FET for programming the 152H, now would like to use it to debug the code.

    Thank you for looking at this post!

  • 0 in reply to Ken Ward
    TI__Expert 7820 points
    Sorry, I did not understand your question. I will repost your question and reply the same to your other thread - if you want you can continue there.

    To debug with the SensorHub (or even the "Default") project, the ROM code needs to be told to maintain the JTAG connection. The risk is that the ROM code references the same pins (or switches on the EVM) for its settings as the JTAG connection uses. So if it is told to maintain JTAG, then it will still read the P1.7-P1.4 pins, but they will be set by the JTAG protocol. The only significant pin, is P1.7 the master I2C/SPI setting. Since it multiplexes with the JTAG TMS it will usually be low, it will select the master option.

    So what needs to be done to have debug access, is these steps:
    1. Load the SensorHub (or the Default) project
    2. After it loads and is halted, open the Memory Browser.
    3. Find the address: 0xF87D
    4. Write to it: 0x39 - 8-bits only
    5. Then resume debugging
    6. Any breakpoints in CCS will now work.
  • 0 in reply to Ken Ward
    Intellectual 345 points

    After launching the 7970A GUI, I'm wondering if I'm getting it set up correctly before hitting the "Set Protocol" button:

    0. Default is "Inventory", "High Data Rate is unchecked", then "Set Protocol."  If Set Protocol is successful, go to the Test tab.

    1. Is 8-byte block mode the default mode, or must I set it explicitly in the Test tab as "180221FF95FF0000"?

    2. To set up for the Sample and kick off the sample, I send "180221000100700001010000"

    3. Poll reads of Block 0 (first byte) to determine when the New Sample Available bit changes from "01" to "02"

    4. Read Block 9 to find my sample data "18022009".

    This entire sequence is working very intermittently, looking to nail down any loose ends.

    Thanks for looking at my post! 

  • 0 in reply to Ken Ward
    TI__Guru*** 135355 points
    Hello Ken,

    Do you mean to say "High Data Rate is unchecked" or "checked"?
  • 0 in reply to Ralph Jacobi
    Intellectual 345 points
    The "High Data Rate" box is not checked, by default. Should I be using the High Data Rate?

    Should "Inventory" be selected before performing the Set Protocol.

    There are other options that I'm wondering about, such as the Select box, the AGC on box, the Double Sub-carrier box, whether to leave the Data Coding Mode at the default value of "1 out of 4", etc.

    What I'm trying to do, is to get good nominal values selected before performing Set Protocol.
    Next go to the Test tab and enter "180221000100700001010000" to configure the sampling and trigger one sample pass.
    Poll the Status register for "new sample available", where 01 means sampling incomplete and 02 means new sample available.
    Lastly, read Memory Block 9 for the sample results.

    This works correctly sometimes, so I'm trying to nail down the correct sequence for reliable operation.

    Thanks for looking at my post!
  • 0 in reply to Ken Ward
    TI__Guru*** 135355 points
    Hello Ken,

    Yes you should be using High Data Rate.

    Please try setting that and see if that improve performance.
  • 0 in reply to Ralph Jacobi
    Intellectual 345 points
    Yes, checking the High Data Rate box before issuing a Set Protocol command, makes commands/responses work when using the Test tab.

    Thank you for the suggestion!

    Which forum should I use to post a question about the RF430FRL152H I2C operation? What I'm finding is that when I initiate a write to the I2C slave, my scope indicates that the Start condition is created (both SDA and SCL are high, then SDA goes low), but the SCL never starts clocking. That is, clock signals on SCL are never seen.

    Thank you for looking at this post!
  • 0 in reply to Ken Ward
    TI__Expert 7820 points

    The problem is likely on the RF430FRL152H since it is up to the master I2C to start clocking the SCL line.  I suspect you may not have ported the I2C driver code correctly.  I cannot tell exactly from your statements what the problem is.

    I would recommend to step through your I2C code and see if there are any infinite loops that may be occurring.

    If you want, I could review your I2C translation and see if there is anything that stands out.

    You can add code here or I can start a private thread where you can share it there.

  • 0 in reply to Alex K.
    Intellectual 345 points

    Yes, please, I'd like to start a private thread as the code seems too long for a post.  My code is based on the example code.

    I'm wondering if the problem is on the RF430FRL152H, as the 152H Firmware Users Guide indicates in 5.2.1, Table 25 & 26 that pin 8 should be tied low to enable I2C.  Our EE didn't tie pin 8 low, much less bring pin 8 out to a pad.  I suspect that pin 8 is floating.

    Could also send our schematic for review.

    Thank you for your help!