Topics

nrf52840_pca10059 startup


Henrik Brix Andersen
 

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


Carles Cufi
 

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


Henrik Brix Andersen
 

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









Chettimada, Vinayak Kariappa
 

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













Henrik Brix Andersen
 

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










Chettimada, Vinayak Kariappa
 

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










Henrik Brix Andersen
 

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










Henrik Brix Andersen
 

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












Chettimada, Vinayak Kariappa
 

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


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












Chettimada, Vinayak Kariappa
 

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH."  Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



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












Henrik Brix Andersen
 

Hi Vinayak,

Sorry - just getting back to this problem now.

I have double-checked that SB2 is intact and that VBUS_nRF (measured at SB2) is at ~5.20V.
I have a hard time measuring if VBUS_nRF is connected to VDDH since the pin is located underneath the chip.

Could this be faulty hardware?

Regards,
Brix
--
Henrik Brix Andersen

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

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH." Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



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

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












Henrik Brix Andersen
 

Hi again,

I just tried a few of the examples from the nRF5_SDK_15 (open_bootloader_usb_mbr_pca10059_debug.hex and ble_connectivity_s140_usb_hci_pca10059.hex).
Same issue. I am starting to think my nRF52840 dongle is faulty :-(

Regards,
Brix
--
Henrik Brix Andersen

On 11 Sep 2018, at 20.26, Henrik Brix Andersen <henrik@...> wrote:

Hi Vinayak,

Sorry - just getting back to this problem now.

I have double-checked that SB2 is intact and that VBUS_nRF (measured at SB2) is at ~5.20V.
I have a hard time measuring if VBUS_nRF is connected to VDDH since the pin is located underneath the chip.

Could this be faulty hardware?

Regards,
Brix
--
Henrik Brix Andersen

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

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH." Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



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

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