nrfjprog version: 9.7.3 fails nrftool success

[dgerman]

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 !

[dgerman]

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.

[Einar Thorsrud]

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

[dgerman]

Thank you, yet again, for your continuing support.

1)I will look into the Bootloader settings page.

2) So the reason the application is not started is because of "Return false in CRC". Perhaps the next update could revise the log level to  +ERROR.

3) I think I now understand that the reason the app is not started has nothing to do with the memory messages. My efforts to REDUCE the     +memory my application takes were totally missguided. So I guess the SDH:WARNING: is not really WARNINGs ( and surely not CRITICAL).        +Perhaps the next update could change the WARNING to INFO.

Thanks again.