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]

Just 

[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.

[Brad Roberts]

Peripherals used:

SPIM3 @ 32Mhz (NRF_SPIM_FREQ_32M)

WDT @ NRF_WDT->CRV    = 3 * 32768 ; // 3 sec. timeout

NVMC

app_timer

bsp_board_init(BSP_INIT_LEDS);

bsp_board_init(BSP_INIT_BUTTONS);

while (1)
{
    NRF_LOG_FLUSH();
    NRF_WDT->RR[0] = WDT_RR_RR_Reload; //Reload watchdog register 0
    power_manage();

}

[Jared]

Hi,

Thank you for a good explanation of your issue. I'm not entirely sure in which files the workaround is implemented in SDK 16, but have you implemented the workaround yourself in the custom files? Are you able to reproduce the error with an unmodified (but with DCDC enabled) NFC Tag example from SDK 16.0 that uses the precompiled libs?

best regards

Jared

[Brad Roberts]

Hi Jared,

I will try to replicate it using those precompiled libs on SDK 16.0.

B.R>