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.

[AHaug]

Hi Pedro,

I've picked up your case and will be looking into answering your questions. However response time might be longer than normal due to the current summer vacation period here in Norway. I will come back with an answer as soon as I know more, hopefully within the weekend.

Kind regards,
Andreas

[Pedro]

Hi Andreas.

Any news?

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.

[Simon]

Pedro said:

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

Ah, my vacation alings perfectly with yours, I will be back the 15th, so we can continue the investigation then.

[Simon]

Can you put a breakpoint in the function \bootloader\mcuboot\boot\zephyr\serial_adapter.c-->boot_uart_fifo_callback(). That is the interrupt callback that should be called when receiving uart data. When the interrupt callback is triggered, the chip should wake up from idle sleep and the next breakpoint at line 15 should be hit.

If that is not called when running the mcumgr echo command*, could you check the lines with a logic analyzer to see if there is any activity? Is the command actually sent?

*I don't think the list command is supported (see boot_serial.c), but the interrupt callback should still get triggered by image list, so something is going on.

Best regards,

Simon

[Pedro]

Hi Simon,

I hope you had good holidays!

I've finally solved the problem. The communication was arriving to the MCU, BUT to a NFC pin, which by default is configured as NFC.

Just added CONFIG_NFCT_PINS_AS_GPIOS=y to the prj.conf and now all works.

Thank you for guiding me to solve the problem.

Regards,

Pedro.

[Simon]

Ah, I see.

I'm happy you found the cause and thanks for sharing it.

I had a wondeful holiday. I hope you had as well!

Best regards,

Simom