few questions about bootloader settings

[ziv123]

hello Nordic

i am working with nrf52832 soc with SDK 16.0, S132 V7.0.1

following this path:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

and this : https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfutil%2FUG%2Fnrfutil%2Fnrfutil_settings_generate_display.html

1. when trying to read current setting of existing bootloader in the examples i get this:

C:\Nordik SDK\examples\dfu\secure_bootloader>nrfutil settings display pca10040_uart\ses\Output\Release\Exe\secure_bootloader_uart_mbr_pca10040.hex
Bad access at 0x7F000: not enough data to read 4 contiguous bytes
Usage: nrfutil settings display [OPTIONS] HEX_FILE

Error: Failed to parse .hex file: Bad access at 0xFF000: not enough data to read 4 contiguous bytes

why is that ?

2. if i generate a setting for the bootloader and i include the softdevice in the "nrf settings generate command (like so:  --softdevice FILE s132_nrf52_7.0.1_softdevice.hex)

do i still need to mergehex the bootloader with the s132 hex file ? considering that when i flash my application (using SEGGER) after erasing the nrf52832 i do not need to flash the softdevice separately

3. the settings generate command refers to application version, do i need to change the setting each time i change application version or it's name (considering the version is in the name) ?

4. if i mergehex the bootloader settings hex file with the bootloader hex file and i flash the bootloader without having an application flashed on the device, what will happen ? would i be able to flash the application via SEGGER normally or must i have the application hex flashed before the flashing of the bootloader or mergehex with the bootloader ?

that it for now

p.s. 5. in the dfu examples, what's the difference between pca10040_uart to pca10040_uart_debug can both be used for production also can they be used for a PCB not an nrf52832DK ? 

hope to read from you soon

best regards

Ziv

 

[Einar Thorsrud]

Hi,

It seems the UART communication between the PC (nrfutil) and nRF is not working properly for some reason, so we need to digg into that.

• Are you using a DK or custom board?
  • If DK, which DK?
  • If custom board, which pins do you use for UART and have you configured the bootloader to use the correct pins? Do you use flow control?
• Have you used a logic analyzer to check the data on the UART lines? Is there any data exchange at all?

[ziv123]

i don't think its the uart 

look at that:

D:\Ziv\projects\Redent-Nova-FW>nrfutil dfu serial -pkg Redent_0.zip -p COM12 
  [####################################]  100%
Device programmed.

D:\Ziv\projects\Redent-Nova-FW>nrfutil dfu serial -pkg Redent_1.zip -p COM12 

Traceback (most recent call last):
  File "C:\Program Files (x86)\Python383\Scripts\nrfutil-script.py", line 11, in <module>
    load_entry_point('nrfutil==6.1.0', 'console_scripts', 'nrfutil')()
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 782, in main
    rv = self.invoke(ctx)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\__main__.py", line 1055, in serial
    do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, True,
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\__main__.py", line 970, in do_serial
    dfu.dfu_send_images()
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
    self.dfu_transport.open()
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py", line 214, in open
    raise NordicSemiException("No ping response after opening COM port")
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

D:\Ziv\projects\Redent-Nova-FW>

you can see that when there is no application yet, just softdevice and bootloader then the dfu on serial works and i check the application it is working and i am communicating with the application on the same serial.. next i give the application this command 

NRF_POWER->GPREGRET = 0xB1;
NVIC_SystemReset();

and then i close the comm on which i was communicating with the app so it will be free to preform the dfu

and then i go to the terminal and try to dfu as can be seen above

the generate pkg commands:

nrfutil pkg generate --application Output\Pca10040_Debug\Exe\Redent_Nova.hex --application-version 1 --hw-version 52 --sd-req 0xCB --key-file bootloader\src\private.key Redent_1.zip
Zip created at Redent_1.zip


nrfutil pkg generate --application Output\Pca10040_Debug\Exe\Redent_Nova.hex --application-version 0 --hw-version 52 --sd-req 0xCB --key-file bootloader\src\private.key Redent_0.zip
Zip created at Redent_0.zip

[Einar Thorsrud]

Hi,

I see you use the _debug bootloader, so it would be very interesting to see the RTT log. That way we could see if the device enters DFU mode after  you write to GPREGRET and reset or not. Does it? If not, what state is the bootloader in, seen from the log?

By the way, please provide full logs and contexts going forward so I get the full picture when trying to understand what is going on.

[ziv123]

i am not using _debug bootloader

what you might look at "Pca10040_Debug" is a configuration of the app itself

<configuration
    Name="Debug"
    c_preprocessor_definitions="DEBUG;DEBUG_NRF"
    gcc_optimization_level="None"
    hidden="Yes" />
  <configuration
    Name="Pca10040"
    c_preprocessor_definitions="BOARD_PCA10040"
    hidden="Yes" />
  <configuration
    Name="RedentPCB"
    c_preprocessor_definitions="REDENT_NOVA_BOARD;BOARD_CUSTOM=REDENT_NOVA_BOARD"
    hidden="Yes" />

  <configuration
    Name="Pca10040_Release"
    inherited_configurations="Pca10040;Release" />
  <configuration
    Name="Pca10040_Debug"
    inherited_configurations="Pca10040;Debug" />

but i can try to so the same with the debug bootloader.. what do i need to configure to get the full log ?

[Einar Thorsrud]

You should definitely use the pca10040_uart_debug project in this case. That will be very useful. You do not need to do any configuration, just use the debug bootloader project instead of the non-debug project, and if you have made any changes in the "normal" bootloader, do the same in the _debug bootloader. Then simply use it. It has RTT logging enabled by default which will give a lot of information during boot and DFU upgrade.