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

[hmolesworth]

Worth mentioning, should your custom board supply differ from the FTDI voltage or you perform a reset at anytime with the FTDI connected you can get unexpected behaviour due to back-drive from the FTDI to the nRF52840 through the nRF schottky protection. Bootloader operation often relies on a clean reset before or during the transitions from app to bootloader or bootloader to app. The safest way to handle this is to insert a level-translator on the incoming Rx data line, powered from the custom board. It is only required for FTDI use; if there is no such device on the custom board Rx line then it will not be operating as you expect when the FTDI is used, unless you disconnect every time. Not hard to test this to see if it helps.

[AndersLundqvist]

We are aware of that. In fact the custom board is designed to work as a add-on card to the FX30 which uses 1.8V signalling. Therefore we have added level translators on both RX and TX. These level translators should be within specifications even for 3.3V FTDI cables used for PC testing.

[FormerMember]

So that, what is solution ?