Taiyo Yuden EKSKDNZWB support

[Rokk Research]

Hi there,

Does Nordic provide support directly for the Taiyo Yuden EKSKDNZWB Eval Kit and the EYSKDNZWB module?  The Taiyo Yuden documentation seems to suggest that's the case, and it is listed on the 3rd party modules under Nordic's Partner program.

I'm running into some very strange issues with the EKSKDNZWB such as general J-Link flakiness (it requires a power cycle after almost ever operation), and inability to run samples from either the Nordic Connect SDK nor nRF5 SDK v17.1.0 (although samples from the 15.0.0 SDK seem to work), despite having the same nRF52840 revision as the PCA10056 DK.  I can actually get some Zephyr samples running when connected via the Ozone debugger but it's very unreliable.  I've tried 2 different eval kits as well.

The DK has a 32kHZ external crystal, and it looks to be a Revision 2 version of the nRF52840, so I am completely baffled as to what the issues could be.

[Simonr]

Hi

We can indeed help you out with technical questions regarding the third party modules you are using, but we do not have example projects specifically made to support these modules/eval kits, and we can't guarantee that the examples we have will work out of the box.

Can you provide some details as to how the Evaluation kit (let's refer to it as EK for short) is powered up? Have you measured the voltage on the board to make sure that it is properly powered at all times? After a reset or power cycle the RESETREAS register can be read to determine which source generated the reset. You can try doing that to find the reason of these power cycles. Can you also describe the "inability" to run samples from the nRF Connect SDK (NCS) and nRF5 SDK v17.1.0? Do you see any errors when trying to flash example projects onto the EK?

Best regards,

Simon

[Rokk Research]

Thanks for the reply Simon!  We're powering the EK via the Mini-USB port (CN2) which provides 5V to the FT232 chip, which in turn provides 3.3V to VDD and VDDH via jumper on pins 2-3 of CN4.  Regarding the SDK v17.1.0 samples, there is no output on the UART and the module does not advertise, while the same samples from the SDK v15.0.0 do.

Trying to step through the v17.1.0 samples with a debugger results in different behavior, where they do advertise/output to the UART, until the debugger is removed and the module is reset.  Flashing directly appears to work (only after resetting the module between flash attempts), but the v17.1.0 samples won't run.

Thanks for the suggestions, I will verify the voltages and clocks first, then take it from there.

Regards,

-mike

[Simonr]

I'm sorry, but we're not too familiar with the Taiyo Yuden evaluation kit here, but I would suggest reading through the User guide I found here. Maybe that might give you some pointers on maybe a switch being set to not power the board correctly. Can you try configuring your example to use the internal RC oscillator just to make sure it's not the external LF clock that is poorly tuned? Try setting the following defines in sdk_config.h of your project to the following values:

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.

// <0=> NRF_CLOCK_LF_SRC_RC
// <1=> NRF_CLOCK_LF_SRC_XTAL
// <2=> NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.

// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

Best regards,

Simon

[Rokk Research]

Thank you for the suggestions, Simon!  We're evaluating a different module at the moment, but I will give this a try if we decide to stick with the EKSKDNZWB.

regards,

-mike

[Simonr]

Hi Mike

Let me know if you have any further questions regarding technical support on this matter, or if we can close this case. We can also leave it open if you're not sure if we're done.

Best regards,

Simon

[Rokk Research]

Fine to close out, thank you!