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

nrfjprog version: 9.7.3 fails nrftool success

ruuvi is connected to ruuvi dev board to Nordic dev board connected to Mac book pro.

As usual

nrfjprog --family nrf52 --sectoranduicrerase --program  ruuvitag_b/s132/armgcc/_build/ruuvi_firmware.hex
 --verify --reset

But

SDH:INFO:sd_ble_enable: RAM START at 0x20002c00

SDH:warning:sd_ble_enable: app_ram_base should be adjusted to 0x20002798

SDH:warning:ram size should be adjusted to 0xd868

nrfjprog version: 9.7.3

JLinkARM.dll version: 6.33a

+++++++++ So. ++++++

nrfutil pkg generate --hw-version 52                 \

--sd-req 0x91                                         \

--debug-mode                                         \

--key-file ../../keys/ruuvi_open_private.pem         \

--application ruuvitag_b/s132/armgcc/_build/ruuvi_firmware.hex \      $zipname.zip

Email to iPhone, nRFtoolbox DFU and after many

INFO:Sending CRC

...

INFO:Inside main

:INFO:In nrf_bootloader_init

:INFO:In real nrf_dfu_init

:INFO:running nrf_dfu_settings_init

:INFO:Enter nrf_dfu_continue

:INFO:Valid App

:INFO:Enter nrf_dfu_app_is_valid

:INFO:Return true. App was valid

:INFO:Enter nrf_dfu_app_is_valid

My app runs fine !

Parents
  • Hi,

    What exactly is the question?

    If you are concerned about the SDH:warning then this comes from the initialization of the SoftDevice, and is the method the SoftDevice use to let you know how much RAM is needed by the SoftDevice for the current configuration, and consequently how much RAM is available to the application. The warning will disappear if you adjust the RAM start and size in your projects/linker settings.

  • Sorry. The questions ARE:

    1) Why does flash via nrfjprog produce an unusable part?
    PS It's not a "WARNING" if the application is not executed,
    It's CRITICAL!

    2) Why is there a difference when using nrftools succeeds?

    Additional information: After removing the most recently added code and re compiling, 
    nrfjprog returns the same error. Regressing to a previously successfully flashed source and still nrfjprog fails. It was not until flash via nrftools DFU that I was able to use nrfjprog to flash the part!

    Do you need any additional information?

Reply
  • Sorry. The questions ARE:

    1) Why does flash via nrfjprog produce an unusable part?
    PS It's not a "WARNING" if the application is not executed,
    It's CRITICAL!

    2) Why is there a difference when using nrftools succeeds?

    Additional information: After removing the most recently added code and re compiling, 
    nrfjprog returns the same error. Regressing to a previously successfully flashed source and still nrfjprog fails. It was not until flash via nrftools DFU that I was able to use nrfjprog to flash the part!

    Do you need any additional information?

Children
  • I still lack enough details to understand what is actually going on here, but I will try to answer as best I can.

    dgerman said:
    1) Why does flash via nrfjprog produce an unusable part?

    You should not get an unusable part when you program with nrfjprog. That will write your hex files to flash exactly as they are. One thing you need to remember though, is that if you use a bootloader then you also have to program a valid bootloader settings page. If not, the bootloader will not know that there is a valid application in place and it will not start the application. If you program the application via DFU the bootloader will write this for you, but if you want it to work out of the box you have to program it yourself (using e.g. nrfjprog). You can generate it using nrfutil.

    dgerman said:
    PS It's not a "WARNING" if the application is not executed,
    It's CRITICAL!

    This warning does not have any effect if your application has configured a higher start address and lower size than specified in the printout. If your application uses a lower start address and/or larger size, then you will get problems. In any case you simply just have to adjust your linker/project settings according to the warning.

    dgerman said:
    2) Why is there a difference when using nrftools succeeds?

    What do you mean by "nrftools"? Please be more specific in what you are doing when it fails and when it works. I cannot give a proper answer without knowing exactly what you are doing.

    dgerman said:
    Do you need any additional information?

     Yes. Please explain in detail what and how you are doing things, and how it does not work as expected.

  • Thank you for your explanation.

    Sorry (can you revise the title to be nrftoolbox?)

    As I tried to describe in the original  statement:

    "Email to iPhone, nRFtoolbox DFU"

    Using nRFtoolbox for IOS using iPhone with the same hex file flash is successful and application works correctly.

    I believe that with the options I have used, neither nrfjprog nor iOS nrftoolbox is programing the boot loader so the same Bootloader trying to launch the application.

  • dgerman said:
    I believe that with the options I have used, neither nrfjprog nor iOS nrftoolbox is programing the boot loader so the same Bootloader trying to launch the application.

    Even if you have the exact same bootloader it will not launch the application if the bootloader settings page is not valid. Note that this is not part of the bootloader .hex file, as it depend on the application (hash). It will not be valid unless you either 1) generate a valid bootloader settings page using nrfutil and program it using e.g. nrfjprog or 2) upload the application via DFU.

    (I still don't know if this is the problem you are seeing though, as you have not provided a detailed description on what fails and how.)

  • Thanks for the additional information.
    I guess the real question is

    Why does softdevice_handler (?) object with "app_ram_base should be adjusted to 0x20002798" when app is flashed with nrfutil BUT when
    flashed with nrftoolbox there is no problem?

    Please see

    entire nrfjprog log (j-jink was not active) at http://www.myBeacons.info/nrfjprog-180914.log

    output from j-link after reset, go at http://www.mybeacons.info/nrf-log.180914.log 

    output from j-link while DFU using nrftoolbox from iPhone.  www.myBeacons.info/.../DFU.180914.log

    Is there anything else I can provide you with

    Thank you for your continued help with this problem.

  • Hi,

    The bootloader logs made things a lot clearer.

    Let's take the case where you have programmed/upgraded the application via DFU first. In the  logs you see that the bootloader finds a valid application, and will subsequently go on to start the application. (It never initializes the SoftDevice, as it does not need any BLE connectivity):

    :INFO:Inside main
    :INFO:In nrf_bootloader_init
    :INFO:In real nrf_dfu_init
    :INFO:running nrf_dfu_settings_init
    :INFO:Enter nrf_dfu_continue
    :INFO:Valid App
    :INFO:Enter nrf_dfu_app_is_valid
    :INFO:Return true. App was valid
    :INFO:Enter nrf_dfu_app_is_valid

    Then you have the other case in the log below, where you have programmed the application via nrfjprog. In this case, you can see that the app is supposed to be valid, but you also see "Return false in CRC". This is because the bootloader settings does not contain a valid CRC of the application. This is something you have to generate and program, as I have discussed earlier in this thread. As this is missing, the bootloader will enter DFU mode instead of starting the application (as it should). This is the real issue here.

    Now you have the warnings that you were concerned about. They are printed after the bootloader has enabled the SoftDevice (needed to perform DFU over BLE), but clearly the bootloader RAM configuration is not optimal. To fix this issue and get rid of the warnings, simply adjust the RAM start address and size in the bootloader. (However, as you can see, the current start address of 0x20002c00 is higher than the recommended, so there is strictly no need to change anything.)

    :INFO:Inside main
    :INFO:In nrf_bootloader_init
    :INFO:In real nrf_dfu_init
    :INFO:running nrf_dfu_settings_init
    :INFO:Enter nrf_dfu_continue
    :INFO:Valid App
    :INFO:Enter nrf_dfu_app_is_valid
    :INFO:Return false in CRC
    :INFO:In nrf_dfu_transports_init
    :INFO:num transports: 1
    :INFO:vector table: 0x00075000
    SDH:INFO:sd_ble_enable: RAM START at 0x20002c00
    SDH:WARNING:sd_ble_enable: app_ram_base should be adjusted to 0x20002798
    SDH:WARNING:ram size should be adjusted to 0xd868
    :INFO:After nrf_dfu_transports_init
    :INFO:------- nrf_dfu_flash_init-------
    :INFO:Waiting for events

Related