You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Johan de Jong <jd...@dearnova.nl> on 2018/05/31 14:03:37 UTC

Bootloader does not start image

Dear all,

Recently I started playing with mynewt (1.3.0), on an nRF52832 module (which is actually the nRF52832 chip+caps+crystal,LDO mode). For this module, I use board support package '@apache-mynewt-core/hw/bsp/nrf52dk'.

Using Ubuntu 16.04 and a J-Link debugger (fw V10.10) I managed to build the bundled 'bleprph' app, and also the 'nrf52_boot' app.

I added

/* Turn LED on */
int g_led_pin = LED_1;
hal_gpio_init_out(g_led_pin, 1);

directly after sysinit() to visualize the application starting.

Using the J-Link debugger, I executed an 'erase' command. Then I ran the commands:

# newt build nrf52_boot
Building target targets/nrf52_boot
Target successfully built: targets/nrf52_boot
# newt load nrf52_boot
Loading bootloader
# newt create-image nrf52_bleprph 1.0.0
App image succesfully generated: /projects/bin/targets/nrf52_bleprph/app/apps/bleprph/bleprph.img
# newt load nrf52_bleprph
Loading app image into slot 1
#

The tutorial on https://mynewt.apache.org/master/os/tutorials/nRF52/ states that the LED on the Blinky example starts flashing, so in my case I expect the LED to turn on. This does not happen.

Then I restarted the module by a power cycle, expecting that the bootloader takes the image in slot 1, verifies it and copies it to slot 0, and executes it, and thus the LED should turn on. Also, this does not happen.

But when I run the code using 'newt run nrf52_bleprph 0', and when I start the debugging using J-Commander 'c', the LED turns on and the module can be detected by my phone.

Now I wonder what step in the process does go wrong, as building, loading and running seems to go fine.
Is there any recommended method to debug this scenario? (I'm using J-Link Base, so no trace capabilities)

Regards, Johan

Re: Bootloader does not start image

Posted by Alvaro Prieto <al...@verily.com>.
Hi Johan,

I see your NRF52 board is supposed to be in LDO mode. Did you
set MCU_DCDC_ENABLED:0 in your syscfg.yml to make sure it doesn't try to
use the builtin DC-DC converter?

https://mynewt.apache.org/develop/mynewt_faq.html#issues-running-image-on-boot

Cheers,

Alvaro

On Thu, May 31, 2018 at 7:03 AM, Johan de Jong <jd...@dearnova.nl> wrote:

> Dear all,
>
> Recently I started playing with mynewt (1.3.0), on an nRF52832 module
> (which is actually the nRF52832 chip+caps+crystal,LDO mode). For this
> module, I use board support package '@apache-mynewt-core/hw/bsp/nrf52dk'.
>
> Using Ubuntu 16.04 and a J-Link debugger (fw V10.10) I managed to build
> the bundled 'bleprph' app, and also the 'nrf52_boot' app.
>
> I added
>
> /* Turn LED on */
> int g_led_pin = LED_1;
> hal_gpio_init_out(g_led_pin, 1);
>
> directly after sysinit() to visualize the application starting.
>
> Using the J-Link debugger, I executed an 'erase' command. Then I ran the
> commands:
>
> # newt build nrf52_boot
> Building target targets/nrf52_boot
> Target successfully built: targets/nrf52_boot
> # newt load nrf52_boot
> Loading bootloader
> # newt create-image nrf52_bleprph 1.0.0
> App image succesfully generated: /projects/bin/targets/nrf52_
> bleprph/app/apps/bleprph/bleprph.img
> # newt load nrf52_bleprph
> Loading app image into slot 1
> #
>
> The tutorial on https://mynewt.apache.org/master/os/tutorials/nRF52/
> states that the LED on the Blinky example starts flashing, so in my case I
> expect the LED to turn on. This does not happen.
>
> Then I restarted the module by a power cycle, expecting that the
> bootloader takes the image in slot 1, verifies it and copies it to slot 0,
> and executes it, and thus the LED should turn on. Also, this does not
> happen.
>
> But when I run the code using 'newt run nrf52_bleprph 0', and when I start
> the debugging using J-Commander 'c', the LED turns on and the module can be
> detected by my phone.
>
> Now I wonder what step in the process does go wrong, as building, loading
> and running seems to go fine.
> Is there any recommended method to debug this scenario? (I'm using J-Link
> Base, so no trace capabilities)
>
> Regards, Johan
>