Wrong message length reported by MB_LEN_Dyn

[NDvas.3]

While doing an FTM transmission from RF to I2C and reading the MB_LEN_Dyn register, it will always report a length which is 6 bytes more (or 7 after the increase by one in my code) than the actual message length.

Below is the code of the ISR handling this. Can you please let me know what am I doing wrong?

On the mobile side, I am running the NFC Tap and using the FTM - Data Transfer screen.

Thank you,

Nir.

void IOCAF3_ISR(void) {    
    
unsigned char RX_BYTE,i;   
unsigned char length;
       
           
          RX_BYTE= ST25_readbyte(FTM_MEMORY,ST25_DYNAMIC_REG_IT_STS);
                           
          if ( ( RX_BYTE & 0x20 ) == ( 0x20 ) )
          {    
            
          RX_BYTE= ST25_readbyte(FTM_MEMORY,ST25_DYNAMIC_REG_MB_CTRL);    
              
          if ( ( RX_BYTE & 0x85 ) == ( 0x85 ) )
          {
          
          length= ST25_readbyte(FTM_MEMORY,ST25_DYNAMIC_REG_MB_LEN);
          length++;                   
          printf("\nLength %d\n\r",length); 
          for (i=0;i<length;i++)
          {
          data_buffer[i]  = ST25_readbyte(FTM_MEMORY,ST25_MAILBOX_START+i);    
            
          }
          
          for (i=0;i<length;i++)
          {
            
          printf("\n %d\n\r",data_buffer[i]);     
          }
 
          
          
          }
            }
          IOCAFbits.IOCAF3 = 0;
}

[JL. Lebon]

Hello,

Your code looks find to me (except maybe for the "unsigned char length" which I would rather declare as an unsigned short to avoid an overflow when doing length++ with a message of 255 bytes).

You say that the length is always 6 Bytes more than the actual message length.

Can you please tell me how do you know the real length of your message ?

Best regards.

[NDvas.3]

Hey JL,

Thank you. Please see attached the screen shot from the NFC tap. In this case, i was sending "12" which is suppose to be 2 bytes long.The output i got for this from my serial logger is:

113,  7 ,  5,  49,  50,  23,  4,  219,  103

As you can see, there 9 bytes here. Only the bolded ones (which I have bolded here) are the actual data (ASCII representation of 1 and 2). I do not know what the App sends out but I thought it would

just be the data itself. Is there a prefix or suffix sent?

Mind you, I found a clue to this mystery. The second byte (in this case 7) will always be in the value of the length i get (in this case 9) minus 2. Maybe this can help explain something.

Thank you for your help,

Nir

[JL. Lebon · Accepted solution]

Hello Nir,

Ok, yes. The NFC Tap is using a kind of SW protocol on top of the FTM feature to allow control and error check for long data transmissions. It is meant to be used with the ST25DV-DISCOvery board, which understand this protocol for its FTM embedded demos.

Basically, this protocol adds some headers and CRCs to the data you want to send. The STM32 FW of the ST25DV discovery kit is able to decode those headers and CRC so that the whole system is able to detect errors and eventually retransmit packets.

In your example, the first byte "113" means that the data sent is a full segment of data, that next byte is the length of data transmitted and that CRC is present.

The next one "7", as you guessed, is the length of data to come.

Then you have "5" which means in this SW protocol "FTM send data"

Then you have your 2 bytes of data.

And finally 4 bytes of CRC for this packet.

This protocol is an example of what can be done on top of FTM. You can get the source code here and see how it works: https://www.st.com/content/st_com/en/products/embedded-software/st25-nfc-rfid-software/stsw-st25ios001.html

Best regards.

[NDvas.3]

Oh! I spent almost 5 hours trying to figure out what's going on! I think it will be a good

idea to note this somewhere so that someone using the NFC Tap with a dedicated hardware would be aware of this.

Anyway, thank you for your help!!

Nir