1839131_en-US

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

1839131_en-US

1839131_en-US

NTAG5 Link SRAM Offset

Hi,

I'm working on an application with an NTAG5-LINK (NTP53121) NFC chip.
We want to use this chip in Passthrough mode.
I'm using the example code from SW6090 on my board, and the Android App build from SW5870.

In principle this is working OK.
However, when reading the content from SRAM written by NFC (from the Android App) over I2C by the microcontroller (address 0x2000 - 0x203F), I noticed that the data written by NFC actually starts at address 0x2004...

When digging into this issue I found that the Android App code mentions:

Initialize SRAM data for RF->I2C mode, not possible to send the whole SRAM (256 bytes)
in a RF command
because of the NFC API limitation,
thus the first 2 blocks of the SRAM will not be written and the final lenght is 250 bytes.
[Note the 2 typos: it's 4 blocks, and final length is 240 bytes]

 And indeed the cmd_writeSRAM command in the App uses offset 0x04 to start writing the SRAM data.
This explains the observed behavior.
However, I cannot find any reference to this 'limitation' anywhere else.
Do you know where to find it?

Since I couldn't find the source of this limitation, I experimented with the offset.
And I indeed found that when decreasing the offset below 0x04, the microcontroller no longer gets triggered to read the data from SRAM.
Details:

  • this means that for some reason the Event Detect pin of the NTAG5 chip does not signal the reception of new data over NFC.
  • By force reading the SRAM content, it appears no data was written to SRAM by NFC at all

So it seems that indeed there is, for some reason, a limitation of sending data to the NTAG5 SRAM from an NFC device.
Although I'm kind of OK with this minor limitation (now that I know about it), I would like to understand the limitation.

So is there any more information available about it?
Thanks in advance.

Re: NTAG5 Link SRAM Offset

I got an update from NXP:

Please keep in mind that these apps' examples are for demonstrating purposes, and optimization of them is welcome.
Since the NTAG 5's SRAM buffer is 256-byte is possible I understand that it is possible to achieve the full-length reading but, since this limit has been described, I have to recommend to please develop you application using our API limits to avoid a malfunction of the NTAG 5 IC.

Not the explanation I was hoping for, but I suppose this is all I will get.
So I'll have to accept as is, and live with the small limitation.

Re: NTAG5 Link SRAM Offset

Hello Fabian,

thanks for the quick answer, and your support.

It's unfortunate there is no more documentation about the limitation.
I would really like to understand the background of it.

It's also strange the issue is unknown to you, as it is actually in the source code of the Android App (SW5870) (and for that matter also in the iOS App (SW6133).

Is there anything I can do to help you to analyse the issue?
May I suggest you to try to reproduce the issue?
It's just applying the hardware and SW for SW6090 with SW5870/SW6133, nothing special.

When you run the sample application, you will notice 3 things:

  • When you check the content of sramBuff (for some reason it is not copied to gSRamData in the example, but that's a minor issue), you will see the first 16 bytes are 0x00, and the data from the Android App ({ 0x00, 0x01, 0x02 ... }) starts from byte 16, which shows the offset of 4 blocks
  • When you change the 4th byte (Block Address parameter) in cmd_writeSRAM in the App from 0x04 to something below 4, the write to SRAM from the App is not detected by the microcontroller, keeping it waiting for new data
  • And actually you will also notice something similar in the data going the other direction: The first 4 bytes of gSRamDataFixed send by the microcontroller is not shown in the Android App.
    This is because the 4th byte (Block Address parameter) of cmd_readSRAM of the App is 0x01, indicating SRAM should be read from block 1.
    When this byte is changed to 0x00, the whole content of the SRAM is read as expected (so this actually is working for the full 256 bytes)
Re: NTAG5 Link SRAM Offset

Hello sir,
This is Fabian, I've been assigned to support your case.
I appreciate your interest in our products.
Unfortunately, we don't have a statement on this limitation. Since the reading from SRAM is a custom command and feature, this is part of NXP and the developed API for interfacing directly with the NTAG 5 using the provided utilities from the SW5870.
Regarding the issues you experienced when decreasing the offset, it is quite strange, we haven't had similar issues from other customers that we know about.

Tags (1)
No ratings
Version history
Last update:
‎11-21-2025 04:24 PM
Updated by: