NFC Write Not Working SDK 17 after working consistently for weeks

[peterg0313]

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.

[ovrebekk]

Hi 

Does it start working again if you reset the nRF52DK?

What if you erase the chip and reprogram it, does that make a difference?

Do you have another phone or NFC reader device at hand that you could try, to see if it is somehow related to the reader or just to the nRF52DK?

Best regards
Torbjørn

[peterg0313]

I tried pushing the reset button on development board and then writing to the nfc tag, no luck, I tried erasing the chip and running the code again, still no luck. 

I tried with another phone, an iphone, and the error, nfc tag not supported came up. But that is so strange because I have had this working consistently for a long time, I am using the tag given with the nRF52 development board.

[peterg0313]

To give the situation more context, I am implementing aspects of the wrtiable ndef message example to some firmware I have written for a custom board using the same nrf52 chip as the development board. I was testing the firmware on the development board since I didnt have the actual one yet. I got it working for weeks and now that the actual board has arrived the nfc write feature is not working and neither is the nfc writing firmware on the development board. This is really strange and I dont know how firmware that was working for weeks on the development board does not work on the development board anymore. 

[ovrebekk]

Hi

That is really odd. 

What happens if you try a simple read only example, like the record_text example in the SDK?

Best regards
Torbjørn

[peterg0313]

It does work with the record_text example. The nfc tag is coming up as a mifare tag which I dont think that nfc tools can write to. However, I dont believe the nfc tag was always coming up as a mifare tag. I debugged with someone else who has the board and in there case the tag came up as a different type which nfc tools can write to. The issue seems to be that somewhere in the debugging process when I tested the custom board both the tags I was using all the sudden came up as types that nfc tools can not write to when before the antenna was a type that nfc tools supported. 

[peterg0313]

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?

[ovrebekk]

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

[peterg0313]

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. 

[peterg0313]

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?

[ovrebekk]

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