Hi
Am developing a system based on the audio headset app, although wish to add NFC pairing.
I'm using V2.5.2 still as the apps we are working with have changed significantly. We will migrate the operation on our development hardware soon to be initiated.
We are working with nRF5340 Audio DK to verify as much as possible before commtting to our hardware design.
The Audio DK NFC buttons are configured for volume and we wish to have these for NFC, so reading the contents of the address below give 0xFE as expected:
#define UICR_APP_NFC_TO_GPIO_ADDR (NRF_UICR_S_BASE + 0x28U) // NFC pins address for nRF5340
The documentation for the UICR seems to state the only way to set back the NFC pins reg to 0xFF for re-enabling the NFC pins (especially if this has changed twice) is to Eraseall the flash. I tried this in my code using VS code, and the Audio DK had issues with doing this at runtime due to access protection VS code asked if I wanted to recover, which I declined but I went to command line instead and typed nrfjprog --recover which tells me it has erased UICR. But when I run code again to the NFC pins register is still set to 0xFE NFC to GPIO.
Our production hardware will have an unwritten flash so this will free-from be an issue for then. But it is essential for us to get this functionality up and running now to validate the pairing design.
Prior to attempting to flash I attempted to read the 64 bit segger SN and this was 0xFFFFFFFFFFFFFFFF obviously this is not the serial number. This was from using the audio headset app existing function uicr_snr_get() in uicr.c/h. If the UICR is completely erased, does the SNR have to be flashed back in and where is this stored?
I have seen the post on MWU disable / enable for writing to UICR, is that required for run time erasing as well as writing? (Case ID: 113741)
Is there an 'in code' and a command line method that you can share to work round this?
Thanks
Laurence.
