Separate MCUboot .hex not working

[Pedro]

Hi,

I have an application using MCUboot (Only for using with serial recovery. No SMP server running in app).

I enable CONFIG_BOOTLOADER_MCUBOOT and parent and child images are generated automatically.

As far as I know:

• build/mcuboot/zephyr/zephyr.hex: only mcuboot

• build/zephyr/zephyr.hex: only application

• build/zephyr/merged.hex: mcuboot+application

• build/zephyr/app_update.bin: signed bin for FW upgrade

When I flash just mcuboot and try to boot in serial recovery mode, there is no response to mcumgr image list or image upload commands (Error: NMP timeout).

If I flash merged.hex and try to boot in serial recovery before any app execution, the same problem occurs, there is no way to boot in serial recovery. Is only after booting to app at least 1 time after hex flashing, I can boot in serial recovery and list image or upload a new one.

Any clue why is this happening?

Another question is about build/zephyr/zephyr.hex (Only app). This hex has an offset so app will be flashed just after MCUboot, and if I flash just this file, app does not boot. 

Is there any option to generate also an hex for flashing just app without bootloader?

If I flash the 'just app' bin at zero offset, Will it always work?

Thanks in advance!

Pedro.

[Pedro]

Hi Simon,

I tested your colleague example with the following results:

Board	.hex	Result
nRF52840-DK	Just MCUBoot	Serial recovery OK
nRF52840-DK	Merged	Serial recovery OK
Arduino Nicla Sense ME (nRF52832)	Just MCUBoot	Can't boot in serial recovery
Arduino Nicla Sense ME (nRF52832)	Merged	Can't boot in serial recovery

Exactly same example, only change is that I've used GPIO 11 for nRF52840-DK and GPIO 29 for Arduino Nicla Sense ME.

I've tried with NCS v1.9.0 and NCS v2.0.0 with same results.

With my app I can boot Nicla Sense ME board in serial recovery if at least one execution of app after flashing (As I explained in the first post), but with your colleague example even booting to app first and then trying to boot in serial recovery, it never works.

About my other questions:

Is there any option to generate also an hex for flashing just app without bootloader?

If I flash the 'just app' bin at zero offset, Will it always work?

Thank you again for your help.

Regards,

Pedro.

[Simon]

Do you have an external LF crystal on the Arduino Nicla ME board? If not try to enable the internal RC:  What is needed in NCS/Zephyr to make nRF52840 module (Fanstel BC840) to use RC instead of external crystal? 

Best  regards,

Simon

[Pedro]

Arduino Nicla Sense ME has an external LF oscillator (See schematics), Anyway I tried enabling the internal RC but nothing changed. Still not working.

I've used this config options:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

Do you have a board with nRF52832 and can try the example?

Regards,

Pedro.

[Simon]

I tested the sample with an nRF52 DK and it worked fine. I did the following:

Set CONFIG_BOOT_SERIAL_DETECT_PIN to 13

• Built and flashed the sample with NCS v1.9.0, and ran it. I saw that led2 was blinking, so it was working
• Modified the sample to blink LED1 instead (dk_set_led_on(0)) and built it without flashing
• Ran nrfjprog --com to see what com port to use and got the following output:
  • 682968457    COM17    VCOM0
• Then I pressed button1 and reset the device
  • I did not see LED1 blinking, which means that it stopped in mcuboot and the app didn't run
• Then I ran the following commands to perfom the DFU and reset the device
  •  mcumgr conn add acm0 type="serial" connstring="dev=COM17,baud=115200,mtu=512"
  • mcumgr -c acm0 image upload build/zephyr/app_update.bin
  • mcumgr -c acm0 reset
• I could then see that the DFU was successful, since LED0 was blinking (new application is running)

The dk_buttons_and_leds library (which is used the blink the LEDs) will look for led nodes which should be defined in the board folder for the nRF boards. I'm not sure if the Arduino Nicla Sense ME board has this. You could just use the GPIO API instead, like done in the Zephyr Blinky sample.

Also, how does the Arduino board expose the UART? For the nRF52 DK we have an Interface MCU which works as a USB to UART Bridge (virtual COM port).

Pedro said:

With my app I can boot Nicla Sense ME board in serial recovery if at least one execution of app after flashing (As I explained in the first post), but with your colleague example even booting to app first and then trying to boot in serial recovery, it never works.

Would you be able to debug with your app a little more? Does it go into boot_serial_start()-->while loop? Have you checked the lines using a logic analyzer, is there any activity going on there?

Let me know if anything is unclear, or if you need help debugging.

Best regards,

Simon

[Pedro]

Hi Simon,

Simon said:

I'm not sure if the Arduino Nicla Sense ME board has this. You could just use the GPIO API instead, like done in the Zephyr Blinky sample.

Yes, I did that. I used a board GPIO and connected it to an external LED.

Simon said:

Also, how does the Arduino board expose the UART? For the nRF52 DK we have an Interface MCU which works as a USB to UART Bridge (virtual COM port).

Same with Nicla Sense board. It has an ATSAMD11 which acts as a Serial to USB Bridge.

I tested it again and did the following:

• Set CONFIG_BOOT_SERIAL_DETECT_PIN to 29.
• Configure GPIO 11 as output and connect an led.
• Connect GPIO 29 to VCC with a 4k7 pull up resistor.
• Built and flashed the sample with NCS v1.9.0, and ran it. I saw that external led was blinking and a periodic message was being received on COM9 @ 115200 baud.
• Then I connected GND to GPIO 29, pressed reset and once released, disconnected GND so GPIO 29 was connected again to VCC through pull up resistor. 
  • I did not see LED blinking, which means that it stopped in mcuboot and the app didn't run
• I disconnected Putty from COM9 to release the port.
• Then I ran the following commands:
  • mcumgr conn add com9 type="serial" connstring="dev=COM9,baud=115200,mtu=512"
  • mcumgr -c com9 image list
• The result was "Error: NMP timeout". If I try with image upload it remains at 0.00% progress forever.

Simon said:

Would you be able to debug with your app a little more? Does it go into boot_serial_start()-->while loop? Have you checked the lines using a logic analyzer, is there any activity going on there?

I connected a J-Link to SWD interface and put breakpoints at the following lines marked with (*):

boot_serial_start(const struct boot_uart_funcs *f)
{
    int rc;
    int off;
    int dec_off = 0;
    int full_line;
    int max_input;

    boot_uf = f;
    max_input = sizeof(in_buf);

(*) off = 0;
    while (1) {
        MCUBOOT_CPU_IDLE();
(*)     MCUBOOT_WATCHDOG_FEED();
        rc = f->read(in_buf + off, sizeof(in_buf) - off, &full_line);
        if (rc <= 0 && !full_line) {
            continue;
        }

When GPIO 29 is to VCC, breakpoints are never reached and led start blinking. Then I connected GPIO 29 to GND and started debugger and it stopped at line 12, then pressed resume and never stopped at line 15. Maybe something wrong with MCUBOOT_CPU_IDLE();?

The mechanism for going to bootloader seems to be working, but for some reason communication is not working.

I also tried all explained above with ncs v2.0.0 (Which is the one I'm using for my project) with same results. 

Any idea?

Thank you!

PS: I'll be on holidays until August 16^th and I'll not be able to test something until I come back.