Is ST25 software library able to handle contactless memory with blocks of 2 bytes (for example SR176)?

[ASiro.1]

Hello,

in our project we need to handle the SR176 memory by the ST25r3911B component but we have some problems when we try to write the user blocks of the memory.

We need also to handle the SRI512 card and we are able to write the blocks without problem.

We have noticed that one difference between the two cards is that SR176 is organized in user blocks of 16 bit, the SRI512 is organized in user blocks of 32 bit. We have also noticed that the library function rfalSt25tTPollerWriteBlock doesn't receive the number of bytes to write, but this value is fixed in the code by the define RFAL_ST25TB_BLOCK_LEN = 4.

Could this be a problem for our application which needs to handle the SR176 card? Is it possibile to change this value in the library?

Thanks in advance for your help, Andrea.

[Ulysses HERNIOSUS]

Hi,

I wasn't aware that these (very old) tags are still around. I assume you want to read/write both SR176 and SRI512 from the same application.

I can for now ony recommend to implement your own functions for handling the smaller block sizes of SR176. Just changing the value in the library should work for SR176 but will kill read/write of SRI512.

The changes should be easy, just duplicating the read/write functions, changing its I/O params and the generated RF frames.

Regards, Ulysses

[ASiro.1]

Thank you for your fast answer Ulysses,

we have already changed the value of RFAL_ST25TB_BLOCK_LEN configuring it at 2, but it doesn't seem enough to have the function working with SR176 card.

Checking the parameters of the function we have seen that there are other two parameters configured in this way:

RFAL_TXRX_FLAGS_DEFAULT, (RFAL_ST25TB_FWT + RFAL_ST25TB_TW)

Do you think these parameters need something different depending on the type of card ?

Another question: do you have an older code able to handle a SR176 card?

In the meantime we'll investigate a little bit more, I'll keep you informed about our result.

Andrea

[ASiro.1]

Hello Ulysses,

we need an urgent support about this issue because we have a lot of SR176 cards on field and we must support them again.

Please, I'm asking your help to solve the problem.

As I told you in my previous post, we have verified that the solution RFAL_ST25TB_BLOCK_LEN = 2 is not enough. I asked you if something related to the other parameters must be changed ( I'm referring to define RFAL_TXRX_FLAGS_DEFAULT, RFAL_ST25TB_FWT, RFAL_ST25TB_TW). What do you think about this?

We have also verified that the buffer of data passed to the st25r3911WriteFifo seems correct: in case of SR176 we have 4 bytes, the first byte is 0x09 (command to write), the second is the number of the block and then we have two bytes of data.

I also want to highligth that sometime we have seen the write working with SR176 card, expecially when we are in debug mode, but we are not able to repeat it: the success of the operation seems random. Could this result be the consequence of a timing problem?

Please, could you suggest us in which direction we must invastigate again?

Thanks in advance, Andrea

[Ulysses HERNIOSUS]

Hi Andrea,

-- edited 

AS ST25TB and SR176 don't provide an immediate response to a write command the write verification is done by means of a read command in rfalSt25tbPollerWriteBlock().

1. Is the read command known to be working in other conditions?
2. Did you check that after resetting the device the new data can be read?
3. You can try to put a delay in rfalSt25tbPollerWriteBlock() between the actual writing and the reading

Regards, Ulysses

[ASiro.1]

Hello again Ulysses and thanks again for your help.

I try to answer to your question:

1) we are able to execute a read command in other condition because we can read the UID;

2) when we the write operation is executed with success, we can read back the data written after reset of the device;

3) I try as soon as possibile to insert the delay.

Andrea