This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NFC Write Not Working SDK 17 after working consistently for weeks

I am currently trying to test the writable ndef message example on my nrf52 development board. I have gotten it to work so many times in the past weeks but now it seems when I use NFC tools to write a message to the nfc tags I get the error on nfc tools, "write error". I am really confused as to what the issue can be hand have tried almost everything suggested in the forums to no avail. I will provide a screen shot of the appearance of this error message. 

The code is literally the exact writable ndef message example which is why I left it out. Just wondering if any one has some possible solutions or approaches to try. Thank you.

  • Is there a way that the type of an nfc tag can all of the sudden change in code somehow because it doesnt seem likely?

  • Hi

    I guess what you refer to as the tag is just the external antenna that is provided with the DK. 

    All the NFC configuration and data is controlled by the nRF52832 chip, and whatever software you put into it, so it is very odd that you can not get it to behave like before if you erase the nRF52832 flash content and reprogram it with the original example. 

    Have you double checked that the NFC antenna is securely mounted to the connector, and that it didn't get loose?

    Best regards
    Torbjørn

  • Yes I am referring to the external antenna. And as far as I have checked the antenna is in there properly. When I go to read the tag it identifies and reads it so I am not sure why I can't write to it.  I have checked with multiple similar antennas. One another person's board the the firmware still works all together. However, another person who has the development board and the same firmware I wrote has their stuff still working. They did not go through the process of erasing the chip. I did. That's when issues began to arise because I never had these issues before erasing the chip.

    Does the erasing process corrupt the data in some register that is important for nfc wite to work? A third person I tested with had their dev board and erased the chip before uploading code. Then when they tested, they got the same error as I did. It seems to be linked to the erasing of the chip. The error is typically in the form of "this tag type is not supported" when I test with nfc tools, however, when I tested with the other person who faced similar issues their board came up as a ISO 7816 while mine came up as something else, something in the class of mifare tag. I believe ISO 7816 is supported by NFC tools and mifare is not. Yet errors persist. 

  • I am seeing that there is a way to reset the cpu of the device completely on the development board. I think it is called NVIC System Reset. How do I do this exactly for the nrf52 implementing sdk 17, or is it a sdk independent process? Do you suggest such a reset for trying to debug this issue? Is there any risk involved?

  • Hi 

    Can you let me know how exactly you erase the chip?
    Doing a chip erase is a standard part of the development process, and should not affect the functionality of the device in any way (assuming you flash the application back afterwards, as well as any UICR configuration that was lost by the chip erase). 

    The only thing that might cause long term issues is if the FICR area is somehow corrupted, but an eraseall should not affect FICR. 

    Maybe you could perform a FICR readout of your device and send me the result?

    nrfjprog --readficr file.hex

    peterg0313 said:
    I am seeing that there is a way to reset the cpu of the device completely on the development board. I think it is called NVIC System Reset. How do I do this exactly for the nrf52 implementing sdk 17, or is it a sdk independent process? Do you suggest such a reset for trying to debug this issue? Is there any risk involved?

    A system reset will only reset the CPU program counter, reset peripheral registers to their default values and restore GPIO configuration to default. It should not have any permanent effects, such as affecting flash memory content. 

    To perform a so called soft reset (software initiated reset) you can simply call this function in your application:
    NVIC_SystemReset();

    You can read about the various reset types here. Scroll to the bottom for an overview of what the different reset types actually reset.  

    Doing a reset is a risk free process and is quite normal to do if some critical program error occurs during runtime, in the hope that restarting the entire application will allow you to recover from the error (this is essentially what the watchdog peripheral is for). 

    Best regards
    Torbjørn

Related