Re: nrf52840_pca10059 startup


Henrik Brix Andersen
 

Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
--
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Where are you applying the 3V? to VDD_nRF or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@...>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@...> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@...> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@...> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@... on behalf of Henrik Brix Andersen" <devel@... on behalf of henrik@...> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen











Join devel@lists.zephyrproject.org to automatically receive all group messages.