Bootloader on custom board using uart

[AndersLundqvist]

Hi,

We have developed a customized board for use in a gateway. We would like to have a working bootloader on that board but it looks like it is almost impossible to make things work.

We are using nRF5 SDK version 15.0.0. I have tested the secure_dfu_test_images for nrf52840 on a PCA10056 board and they do not work as expected, so perhaps I was foolish to think that it would make any difference adapting the secure uart example for our board.

I have tested the uart example on both boards and they work perfectly so there is nothing wrong with the hardware (at least the uart is working properly). I have tried various baudrates since one support case suggested a baudrate of 9600 instead of the 115200 which is default in the bootloader example. I have also read most of the other support cases concerning the dfu and I have not found anything that could explain the problems that I see. I have also altered the python code to make the default baudrate 9600 but I cannot understand how to create a new version of nrfutil. However I assume that using the -b 9600 argument makes those changes unnecessary. 

When trying to upload a new application to the board I get the following response:

pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

I have nrfutil version 3.5.1 (some support cases suggests exactly version 3.0.0 while others say >= 3.0.0).

Now I am out of ideas to try and fix this. Any ideas and/or suggestions?

If it does not work with nrfutil, how am I going to write a similar software to use inside the gateway? Is there a detailed specification for the protocol used by the bootloader/nrfutil? In that case where? (Yes, I know - RTFM, but the documentation is really fragmentet in certain parts and it is far from easy to know where to look).

Best regards

Anders

[AndersLundqvist]

Hi again,

I should be very surprised if it vere the wrong port. COM3 if the FTDI cable, something I have verified more than once using the ..\examples\peripheral\uart\pca10056\blank\ses and not forgetting the new bootloader which, for various reasons, can not use digital signalling to enter DFU-mode. We will use a command over the UART, which works perfectly well by now. The bootloader functionality unfortunately does not.

What is the JLink CDC UART Port? I have never heard of this before. Isn't it just another COM port that is used by the nrfutil? In the real application we will have a gateway (Sierra Wireless FX30) and an add on card (with nRF52840) connected through the serial port. We have neither room nor economy for additional hardware!

If I use the files found in ..\examples\dfu\secure_dfu_test_images\uart\nrf52840, the bootloader and the blinky zip file should have a matching key, right? In my own case, I use the same key for both bootloader and application zip file. Right or wrong? Should I use another different key for the zip file?

We have now ordered a new PCA10056 card to see if that one works better. It should arrive on monday, so we will see then. Is the QIAAAA a problem?

It would also be interesting if you could help me with the nrfutil issue. If I understand it correctly, the exe file has it's python interpreter embedded while the installed (using pip) uses the python version on the computer. I also understand that there is a big issue in the python world moving between version 2 and 3. Do you have any insights on that as well?

Best regards

Anders

[AndreasF]

Hi.

Try this:

Open the project found in examples\dfu\secure_bootloader\pca10056_uart_debug, in sdk_config.h line 1151, put 0 instead of 1.

// <q> NRF_DFU_SERIAL_UART_USES_HWFC  - HWFC configuration
 

#ifndef NRF_DFU_SERIAL_UART_USES_HWFC
#define NRF_DFU_SERIAL_UART_USES_HWFC 0
#endif

Use the following code in dfu_public_key.c:

/* This file was automatically generated by nrfutil on 2018-03-22 (YY-MM-DD) at 12:39:00 */

#include "stdint.h"
#include "compiler_abstraction.h"

/* This file was generated with a throwaway private key, that is only inteded for a debug version of the DFU project.
  Please see https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/README.md to generate a valid public key. */

#ifdef NRF_DFU_DEBUG_VERSION 

/** @brief Public key used to verify DFU images */
__ALIGN(4) const uint8_t pk[64] =
{
    0x65, 0xfc, 0x2b, 0xf8, 0x16, 0xda, 0x01, 0x9a, 0xde, 0x75, 0xd4, 0xa8, 0x47, 0x71, 0x96, 0x21, 0x1c, 0x87, 0x55, 0x69, 0x10, 0x5a, 0xbe, 0x04, 0x57, 0x8f, 0xd2, 0xb0, 0x29, 0x94, 0x56, 0xb8, 
    0xca, 0x03, 0x63, 0xd6, 0x35, 0xc6, 0x4d, 0xa7, 0x81, 0x9f, 0xef, 0xa7, 0xd2, 0xec, 0xb7, 0xf3, 0x07, 0xff, 0x80, 0xaf, 0x7a, 0x3b, 0x4c, 0x19, 0xb8, 0x91, 0xc5, 0x14, 0x3c, 0xe8, 0x76, 0x6d
};

#else
#error "Debug public key not valid for production. Please see https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/README.md to generate it"
#endif

Create a .bat file in your SDK folder (nRF5_SDK_15.0.0_a53641a) with this code inside, and run it from command prompt:

nrfjprog --eraseall
nrfjprog --program examples\dfu\secure_bootloader\pca10056_uart_debug\ses\Output\Release\Exe\secure_bootloader_uart_mbr_pca10056_debug.hex --chiperase
nrfjprog --program examples\dfu\secure_dfu_test_images\uart\nrf52840\mbr.hex
nrfjprog --reset

SLEEP 2
nrfutil dfu serial -pkg examples\dfu\secure_dfu_test_images\uart\nrf52840\blinky_mbr.zip -p COM7 -b 115200 -fc 0

This should now work, and you should see the following in your command prompt:

I've now modified the examples\dfu\secure_bootloader\pca10056_uart_debug example to use no flowcontroll and a baudrate of 115200.

The Jlink CDC UART Port is the driver for the Segger on-board debugger on the DK.

The same key should be used for both the bootloader and the application, correct.  You should not use a different key for the zip file.

QIAAAA should not be the problem.

You should use Python 2.7 for nrfutil. When it comes to nrfutil for Python 3 i refer to this question.

Hope this works for you, good luck.

- Andreas

[AndersLundqvist]

Hi Andreas,

For some unknown reason I am not allowed to make a reply to your latest post, so I do it here instead.

As you can see from the image below it did not quite work as intended...

As you pointed out, the new hardware did nothing to improve the situation but at least we have verified that which is good.

What do we do now?

Best regards

Anders

[AndreasF]

Hi.

Did you try to do as i said in my previous reply? That is open the project found in examples\dfu\secure_bootloader\pca10056_uart_debug, edit sdk_config.h inside the project, edit dfu_public_key.c inside the project, create a .bat file and paste the code i posted in my previous reply.

Because it seems from the screenshot you sent that you did not program using that .bat file, and you are still programming the  nRF5_SDK_15.0.0_a53641a\examples\dfu\secure_dfu_test_images\uart\nrf52840 examples.

I've attached it in this reply.

Fullscreen RUN_THIS_FILE.bat Download

REM nrfutil settings generate --family NRF52840 --application examples\dfu\secure_dfu_test_images\uart\nrf52840\bootloader_secure_uart_debug_without_bonds_mbr.hex  --application-version 3 --bootloader-version 2 --bl-settings-version 2 settingscase.hex

REM ERASE
nrfjprog --eraseall
nrfjprog --program examples\dfu\secure_bootloader\pca10056_uart_debug\ses\Output\Release\Exe\secure_bootloader_uart_mbr_pca10056_debug.hex --chiperase
nrfjprog --program examples\dfu\secure_dfu_test_images\uart\nrf52840\mbr.hex
nrfjprog --reset

SLEEP 2
nrfutil dfu serial -pkg examples\dfu\secure_dfu_test_images\uart\nrf52840\blinky_mbr.zip -p COM7 -b 115200 -fc 0

Please do as i stated above, once you have finished editing the project, compile it.

Download the .bat file i sent you and place it in the SDK folder (nRF5_SDK_15.0.0_a53641a), and then run it.

- Andreas

[AndersLundqvist]

Hi,

Must have sent the wrong picture, sorry for that. It did not work nevertheless.

However, I have ditched the nrfutil that came using "pip install nrfutil" and downloaded a precompiled version which most likely is exactly the same as the one I used initially.

This time it actually worked. I have even made som progress on the bootloader for the custom board. I have come to the conclusion that you need to set the "--sd-req" to an unsupported value for the download to work properly. This is as far as I can remember not mentioned anywhere in the documentation, which I for obvious reasons have not read in it's entirety.

There are some issues left and I will try to figure out what I need to do to make it work.

If I need more help, I will start a new ticket for that. This one is getting clogged up and I can not reply to the last post no matter how I try - must be something wrong with the ticketing system...

Thanks!

Best regards

Anders