This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Customizing a bootloader

If all you need is changing  PHY, Tx power and Device Name in a standard nRF52840, do you need building a new bootloader from the scratch or the is a way to edit the standard firmware,  build a new edited file and finally re-program this file in a standard nRF52840? Thanks

Parents
  • Hi Vidar. Following the Getting started with Nordic's Secure DFU bootloader, a step by step guide, in the A1 step, Generate your own private key. Type this command line:  nrfutil.exe keys generate private.key, all I get is:

    C:\Users\jtorr>nrfutil.exe keys generate private.key
    File found at private.key. Do you want to overwrite the file?  [y/N]
    Traceback (most recent call last):
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\runpy.py", line 193, in _run_module_as_main
        "__main__", mod_spec)
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\runpy.py", line 85, in _run_code
        exec(code, run_globals)
      File "C:\Users\jtorr\AppData\Local\Programs\Python\Python37-32\Scripts\nrfutil.exe\__main__.py", line 9, in <module>
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 764, in __call__
        return self.main(*args, **kwargs)
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 717, in main
        rv = self.invoke(ctx)
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 1137, in invoke
        return _process_result(sub_ctx.command.invoke(sub_ctx))
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 1137, in invoke
        return _process_result(sub_ctx.command.invoke(sub_ctx))
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 956, in invoke
        return ctx.invoke(self.callback, **ctx.params)
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\click\core.py", line 555, in invoke
        return callback(*args, **kwargs)
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\nordicsemi\__main__.py", line 364, in generate
        if not query_func("File found at %s. Do you want to overwrite the file?" % key_file):
      File "c:\users\jtorr\appdata\local\programs\python\python37-32\lib\site-packages\nordicsemi\dfu\util.py", line 69, in query_func
        choice = raw_input().lower()
    NameError: name 'raw_input' is not defined

    ..... but I don't see any private key string to continue, in order to obtain the public key.

    Any comments?

    Thanks in advance.

  • Hi Vidar.

    I need customizing the TXPOWER parameter through BLE in several nRF52840 modules I am testing, in such a way next time they boot up, they will do with their output power set to pos8dBm and not to pos6dBm as is the case now. Would you please help me with a step by step guide?

    I barely understand how to build and program a secure DFU using nRFtools, but I don't know how to build the source file to initiate the process.

    And also, where in within all the blocks the firmware is made up is this parameter defined? In the Bootloader block, in the SoftDevice, in the App_Data, in the Application itself or somewhere else that I am not yet aware? The modules I am testing are from uBlox. Will I need special source files other than if I set this parameter in the module of a nRF52840 DK board?

    Thanks so much

  • Hi Vidar.

    APP_ADV_DURATION is now set to '0' and working fine. 

    One more thing. If I want to revert your modified ble_app_uart peripheral example to PHY_1MBPS modulation (which I imagine is the one you can scan with a standard dongle), would you please tell me which code statements should I edit? I tried on my own editing 'init.config.ble_adv_primary_phy' and 'init.config.ble_adv_secondary_phy' main.c initialization statements, but obviously with not very much success. 

    Thanks

    Juan

  • Hi Juan,

    You can use the advertising_init() function from the original ble_app_uart example in SDK 15.2.0 if you want to revert back to 1M. 

  • Thanks, Vidar.

    By the way. Do you know of any smartphone BT v5.0 PHY_CODED compatible, apart from (I read it somewhere) the ONEPLUS 6?

    Thanks

    Juan

  • Hi Vidar.

    Everything is working flawlessly now. Regarding your modified ble_app_uart example and its PHY_CODED modulation, what is the BLE data rate actually set in this case. 125 or 500 kbps? 

    Thanks.

  • How are you Vidar?

    We have been thoroughly testing your (see above link you sent us some time ago: https://devzone.nordicsemi.com/f/nordic-q-a/40476/unable-to-convert-to-long-range-after-looking-at-umpteen-examples--/157300#157300) modified ble-uart application in several BLE modules and everything works flawlessly except one marginal problem we hope to be able to solve with your help.
    The problem is that all the modules we tested (all from the ublox NINA-B3 family with a nRF52840 SoC inside) running your modified firmware, present an erratic Power-On process (the modules simply don´t switch on, nor transmit anything), whereas when they run a non-modified ble-uart application from the SDK 15.2.0, the problem does not happen. Surprisingly, when the module is being fed from an external power supply and does not switch-on, we can measure a DC consumption of around 6 mA. The problem shows up no matter we feed the module with a power supply or with a battery.
    As far, the only way to boot up the module we found is switching on and off the power supply continuously till it does boot ...
    We suspect that the problem may be related with the nRF52840 Power Module Unit (PMU) which as you know controls the Power-On Reset and the Module initialization.
    My question is. Do you know if some of the modifications which were made on this ble-uart file you sent us were affecting the PMU block? Affecting may be to any of the power mngt library files we've found in the components SDK directory like "nrf_pwr_mgmt.c" or "nrf_pwr_mgmt.h"?
    Apart from this, do you have any suggestion to get around this annoying problem?

    We would very much appreciate your help.
    Thanks so much.
    Regards.

    Juan

Reply
  • How are you Vidar?

    We have been thoroughly testing your (see above link you sent us some time ago: https://devzone.nordicsemi.com/f/nordic-q-a/40476/unable-to-convert-to-long-range-after-looking-at-umpteen-examples--/157300#157300) modified ble-uart application in several BLE modules and everything works flawlessly except one marginal problem we hope to be able to solve with your help.
    The problem is that all the modules we tested (all from the ublox NINA-B3 family with a nRF52840 SoC inside) running your modified firmware, present an erratic Power-On process (the modules simply don´t switch on, nor transmit anything), whereas when they run a non-modified ble-uart application from the SDK 15.2.0, the problem does not happen. Surprisingly, when the module is being fed from an external power supply and does not switch-on, we can measure a DC consumption of around 6 mA. The problem shows up no matter we feed the module with a power supply or with a battery.
    As far, the only way to boot up the module we found is switching on and off the power supply continuously till it does boot ...
    We suspect that the problem may be related with the nRF52840 Power Module Unit (PMU) which as you know controls the Power-On Reset and the Module initialization.
    My question is. Do you know if some of the modifications which were made on this ble-uart file you sent us were affecting the PMU block? Affecting may be to any of the power mngt library files we've found in the components SDK directory like "nrf_pwr_mgmt.c" or "nrf_pwr_mgmt.h"?
    Apart from this, do you have any suggestion to get around this annoying problem?

    We would very much appreciate your help.
    Thanks so much.
    Regards.

    Juan

Children
No Data
Related