NFC is unstable when DCDEN1 is enabled.

[Brad Roberts]

I am using nRF52840 DK on VDD_HV. SW9 (nRF power source) set to USB and I am connecting a USB cable to J3 (nRF USB). SW6 is also set to nRF Only. My IC revision is QIAAD0.

In an effort to further reduce current consumption, I have recently tried to enable DCDEN0 with a REGOUT0 setting of 3V0. This works well. However, if I enable DCDEN1 the NFC communication becomes unstable. The FDT is no longer accurate and sometimes ends us in a timeout NAK. I could see the FDT errors in my NFC sniffer. Setting DCDEN1 back to 0x00000000 makes the problem go away but it consumes more power.

I checked the errata documents and I am not sure if this is related to

[218] NFCT: Frame delay timing is too short after SLP_REQ

I suspect that maybe enabling DCDEN1 has a crippling effect on TIMER4?

My firmware does not use a soft device. It is based on the NFC Tag text example from SDK 16.0.0, but I imported a customized hal_t2t.c from sdk 15.2.0 instead of using the precompiled lib.

I have tested this anomaly on 12 different nfc readers and my firmware becomes unusable on 5 readers which possibly have stricter timing constrainsts.

So my question is: How can I use DCDEN1 without affecting NFC FDT?

Best Regards

[Brad Roberts]

Hi,

Just to add to this...

I enabled UART logging and I could see that I am getting hardfault errors when DCDEN1 is set to 0x00000001;

<error> hardfault: HARD FAULT at 0x0668D20C
<error> hardfault: R0: 0x00000000 R1: 0x00000006 R2: 0x00000000 R3: 0x00000000
<error> hardfault: R12: 0x0000000C LR: 0x00001849 PSR: 0x01000015
<error> hardfault: Cause: Instruction bus error.

There is not code at 0x0668D20C (obviously)...  So why do I get these errors when DCDEN1 is enabled?

The address of the HARD FAULT randomly changes... here are other instances:

<error> hardfault: HARD FAULT at 0x0E7C9248
<error> hardfault: R0: 0x00000000 R1: 0x00000006 R2: 0x00000000 R3: 0x0 0000000
<error> hardfault: R12: 0x0000000C LR: 0x00001849 PSR: 0x01000015
<error> hardfault: Cause: Instruction bus error.

...

<error> hardfault: HARD FAULT at 0x00002B72
<error> hardfault: R0: 0x0000E3AF R1: 0x20000B3C R2: 0x0000FFFE R3: 0x000074C4
<error> hardfault: R12: 0x00000000 LR: 0x00000AA7 PSR: 0x81000015
<error> hardfault: Cause: Data bus error (PC value stacked for the exception return points to the instruction that caused the fault).
<error> hardfault: Bus Fault Address: 0x20008000

...

<error> hardfault: HARD FAULT at 0x68D20D30
<error> hardfault: R0: 0x00000000 R1: 0x00000028 R2: 0x200014CC R3: 0x00000004
<error> hardfault: R12: 0x00000000 LR: 0x000016AF PSR: 0x20000015
<error> hardfault: Cause: Instruction bus error.

Now when I just simply put back  DCDEN1 to 0x00000000, the hard faults disappear.

These hard faults were probably the ones causing the FDT issues... 

Anyway, how can I fix this problem as I really need to enable DCDEN1 to lower my power consumption.

[dmq]

Hi

I seem to have encountered a similar issue as this，I didn't find the errata FTPAN-98.Would you mind show me where to add the follow code?

*(volatile uint32_t *) 0x4000568C = 0x0000702

Thanks!