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

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

[Brad Roberts]

Hi Jared,

I tried the writable NDEF NFC example in SDK 16.0.0 but it cannot replicate the problem because I believe the NFC traffic is too low.

I don't believe the problem is related to any current NFCT erratas because I have ZERO HARDFAULTS when DCDCEN1 is disabled. If this was related to the supposedly "buggy" NFCT hal_nfc_t2t.c from previous SDKs then I should have the same HARDFAULTS when not using DCDCEN1.

As I developer, I find the NFCT precompiled libs from SDK 16.0.0 very restricting and practically useless for doing anything "productive". My current project can never work with precompiled libs in SDK 16.0.0 that is why I am using SDK 15.2.0.

Anyway, I have imported my project to SDK 16.0.0 but using hal_nfc_t2t.c from SDK 15.2.0 and the same HARDFAULTS appear when DCDCEN1 is again enabled.

Do you have any idea what those hardfaults mean btw?

[Jared]

 Hi, 

I understand, it seems the hardfaults are coming from the NFC IRQ. I can't see a clear dependency between the DCDC and the NFC peripheral. A possibility would be that the DCDC switching is affecting the HFXO in the form of noise, but i'm not sure on this. Could you provide a minimal project that would reproduce this issue and the steps to reproduce it? I can make the case private if you prefer it :) 

regards

Jared 

[Brad Roberts]

Hi Jared,

I found a work around by changing the value of an unknown NFCT register used in errata FTPAN-98.

*(volatile uint32_t *) 0x4000568C = 0x00007029;

This allows me to use DCDCEN1 now.

As stated in my first post, my IC revision is QIAAD0 and it is not affected by FTPAN-98. Initial reading on register 0x4000568C resulted in a value of 0x00038148. I divided this default value by powers of 2 until the hard faults stopped coming. I don't know why this works. I blindly tried other unknown NFCT registers before I found this one.

I believe the problem was related to EasyDMA causing memory corruptions in the RAM. This resulted to invalid values inside the stack and thus causing the hard faults. Hard faults caused the delays in which resulted to NFC communication failures in some timing constrained readers.

Follow up questions:

1. Is it possible for you to tell me what register 0x4000568C actually is?

2. Are there other undocumented NFCT registers that can enable 212 kbps and 424 kbps speeds?

I was checking a very early version of the SDK and I came across these registers:

SHUNT_REG_THRESHOLDS  0x40005610

MOD_STEP_FIXED  0x40005614

MOD_STEP_MULTIPLIER  0x40005618 

INITIAL_LOAD_CTRL_VAL  0x40005688 

MOD_STEP_FIXED and MOD_STEP_MULTIPLIER sounded like they could be used to adjust the default 106 kbps communication speed. They don't do anything to my IC Revision though.

B.R.

[Jared]

Hi,

I can't really see any reasons for why the Hardfault would disappear as a consequence of you writing to that register. I'm also not confident in that the Hardfault isn't connected to your usage of a customized hal_t2t.c from SDK 15.2. 

1. The register is an internal undocumented register that we unfortunately don't share any information about. 
2. No, the NFCT peripheral is specified at 106 kbps. 

I need to discuss this case with some of our developers. I'll get back to you when I have more information. In the meantime, could you provide a minimal project that would reproduce the issue and the steps to reproduce it. 

regards

Jared

[Jared]

Hi, 

As mentioned in the previous reply, could you share a minimal project that would reproduce the issue? 

regards

Jared 

[Brad Roberts]

Hi,

I am doing that as of the moment...

I am trying to build on SDK 16.0.0 to show you that it is not a "hal_nfc_t2t.c" problem. But like I said it is quite impossible to get things done with the pre compiled lib. Now I am using trying out "nrfx_nfct.c" from SDK 16.0.0.

[Jared]

Hi,

Ok. I would also state that it's not clear why your Hardfault disappears when you write to that internal register. I also strongly don't recommend writing to any non-documented register as it can potentially damage the chip under certain conditions.