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.

CC1310: Read Status Register

Part Number: CC1310
Other Parts Discussed in Thread: WMBUS, , CC1312R

Hi,

I want to read a status register to get some information about a received rf packet.

I use a CC1310 Launchpad as a wMBus receiver and I have different wMBus senders. Some of them send in T mode and some in C Mode. (I verified it with other software and hardware.)

Since https://www.ti.com/lit/an/swra522e/swra522e.pdf?ts=1638195288205&ref_url=https%253A%252F%252Fwww.google.com%252F point 2.4 it should be possible  to read which format the via RF received wMBus packet had. I used the TMR to find out how to do that and implement a code like this:

/* Check which mode packet had */
uint8_t wMBusMode = 0;
rfc_CMD_READ_RFREG_t readRegCmd =
    {
     .commandNo = CMD_READ_RFREG,
     .address = 0x5178,
     .value = 0
    };

RF_Stat status = RF_runImmediateCmd(rfHandle, (uint32_t*)&readRegCmd );

if (status == RF_StatCmdDoneSuccess ){
    wMBusMode = readRegCmd.value & 0x01;
    //wMBusMode = 0 means T-mode Packet, wMBusMode = 1 means C-Mode Packet
    }

But the result is not correct. As result I mostly get 1 and it does not matter whether my sender send in T-Mode or C-Mode.

Is there something wrong with the Code? Do I have to do that before or after watching at the next entry with "RFQueue_nextEntry();"?

Best Regards

SB

  • At what point do you read this register?

    Normally you would read this register at the start of the packets (when you have received enough bytes to find the length info regardless of which mode you receive

    In your code you should do something like this:

    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
        if (e & RF_EventNDataWritten)
        {
            
            if (!lengthWritten)
            {
                // Do only first time you get the interrupt
                lengthWritten = true;
    
                RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg);
    
                if (RF_cmdReadRfReg.value == 1)
                {
                    // C-mode
                    // Read the length from the position where the length field for C mode packets are found
                    payloadLength = .....
                    
                    // Set the proper length
                    RF_cmdPropSetLen.rxLen = .....
                    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
                }
                else
                {
                    // T-mode
                    // Read the length from the position where the length field for T mode packets are found
                    payloadLength = .....
                    
                    // Set the proper length
                    RF_cmdPropSetLen.rxLen = .....
                    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
                }
            }
        }
    
        if (e & RF_EventLastCmdDone)
        {
            .
            .
            .
            .
    
            currentReadEntry->status = DATA_ENTRY_PENDING;
            currentReadEntry = (rfc_dataEntryPartial_t*)currentReadEntry->pNextEntry;
            dataQueue.pCurrEntry = (uint8_t*)currentReadEntry;
            Semaphore_post(rxSemaphoreHandle);
        }
    }
    

    where

    // CMD_PROP_SET_LEN
    rfc_CMD_PROP_SET_LEN_t RF_cmdPropSetLen =
    {
       .commandNo = 0x3401,
       .rxLen = 0x0000,
    };
    
    rfc_CMD_READ_RFREG_t RF_cmdReadRfReg =
    {
         .commandNo  = 0x0601,
         .address = 0x51E4,
         .value = 0,
    };

    If you are not figuring out in the beginning of the packet is the packet is C mode or T mode, you will not set the length correctly, and your packet will not be received correctly. Most likely you will then run into an error situation, where you have a buffer overflow etc.

    Not sure if you will receive correct info from this register, if RX has been terminated due to errors.

    Siri

  • Hi Siri,

    thank you for your fast reaction.

    You use 0x51E4 here as address in RF_cmdReadRfReg. Which is the right address for CC1310? Because in swra522e I read that the address is 0x5178.

    Best regards

    SB

  • Sorry about that. My code snippet was for the CC1312R. For CC1310 you should use 0x5178.

    Below is a table showing the mapping of status and config registers mapping from CC1310 to CC1312 for the CT mode patch:

    Siri

  • In my software I do not use partial read and I work with RF_EventRxEntryDone for the Rx command and callback. It works and I receive the wMBus packets and can do further interpretetion with the data.

    I only wanted to check the mode of the packet to get more information about the sender. Can the reading of the register be still done when RF_EventRxEntryDone event was reached already?

    BR

    SB

  • Yes, It can. I tested this using SmartRF Studio with CC1312R as the transmitter and a modified rfPacketRX example for the CC1310 as the receiver. SmartRF Studio transmitted C and T mode packets (not wmbus packet format, but wmbus PHY (sync word, encoding etc. ))

    The receiver used fixed packet length and did not use any CRC checks, but it correctly reported C or T mode after each received packet:

    Siri

  • Hi Siri,

    Thank you very much for your help. I build an example like yours and it works fine.

    But in my case I use rfc_CMD_PROP_RX_ADV_t because I need to receive packets longer then 255 byte.

    Does it also work with the advanced_RX command? Because when I only change the RX to advanced_RX and the MAX_LENGTH in your example this mode detection does not work correctly anymore. Does it work when you test it with the advanced RX command?

    If yes could you share your smartrf_settings for the advanced RX command with me?

    Best regards

    SB

  • While the CMD_PROP_RX can do fixed or variable packet length mode, and have a limitation of a 1 byte length field, the advanced command  supports up to 2 bytes length. However, it does not support fixed packet length mode, so you cannot program the radio to receive for example 500 bytes every time.

    If you want to use this mode you need to set maxPktLen to Unlimited or unknown length and then you need to manually cancel the ongoing RX operation once your application has determined that you have received the complete packet.

    It might be that setting it to unlimited, forces you to actually use the partial read entries. I have never tried this.

    I would recommend you to go with the approach described in the app note, using partial read entries.

    Siri

  • Hi Siri, thank you for your answer. Maybe I was not clear with my last post.

    I have a running example which receives wMBus packets with the CMD_PROP_RX_ADV and it works fine. I use a fixed maxPktLen and I do not manually cancel the RX operation. I have different wMBus senders and they send packets with different lengths, but these packets are never longer then (255+CRC) Bytes.

    I just wanted to add this mode detection to get information about the mode of the packet to save it as information to that telegram. After switching from CMD_PROP_RX to CMD_PROP_RX_ADV the reading of the Rf register for wMBus mode identification does not work correctly anymore. But the only thing I changed was the RX command (and the maxPktLength to a fixed value bigger than 255, but that is not the reason here).

    Maybe I miss a change in my code or in the configuration for CMD_PROP_RX_ADV to enable the reading of the Rf register for wMBus mode identification or I missed information that this mode detection is only possible with CMD_PROP_RX.

    Do you know any reason why mode detection with read rf register should not be possible with CMD_PROP_RX_ADV or if there are any further changes necessary for that?

    Best regards

    SB

  • Hi

    I did not think of setting the header to 0 to achieve fixed packet length. Sorry for that.

    I am able to see the same thing as you are, but I see this also with the normal RX command.

    If I transmit C-mode packets, the radio will always detect them as C-mode, regardless of which command is being used.

    For T-mode packets, it seem like the radio is only reporting it as T-mode is you are actually receiving 3-out-of-6 encoded data.

    I tested the following:

    CMD_PROP_RX and fixed packet length 50

    If I send more than 50 bytes that are correctly encoded, all packets are reported as T-Mode packets

    If I send only 30 bytes packets, it look random if the packet is reported C or T mode.

    Using the advanced command I see the same. I tested with packet length set to 150, since I cannot send more than 255 bytes long packets with SmartRF Studio. Packets longer than 100 bytes (all received data properly encoded) are reported as T-mode, shorter packets seems random.

    I guess that this is OK if you actually implement a proper receive of wmbus packets. Then you would determine right after sync if it is C-mode or T-mode, to be able to configure the SET_LEN command correctly.

    BR

    SIiri