nrfjprog version: 9.7.3 fails nrftool success

RE: nrfjprog version: 9.7.3 fails nrftool success

dgerman — Tue, 18 Sep 2018 02:11:56 GMT

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.

RE: nrfjprog version: 9.7.3 fails nrftool success

Einar Thorsrud — Mon, 17 Sep 2018 08:32:42 GMT

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

RE: nrfjprog version: 9.7.3 fails nrftool success

dgerman — Fri, 14 Sep 2018 15:20:34 GMT

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.

RE: nrfjprog version: 9.7.3 fails nrftool success

Einar Thorsrud — Fri, 14 Sep 2018 12:48:21 GMT

[quote user="dgerman0"]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.[/quote]

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.)

RE: nrfjprog version: 9.7.3 fails nrftool success

dgerman — Fri, 14 Sep 2018 12:12:20 GMT

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.

RE: nrfjprog version: 9.7.3 fails nrftool success

Einar Thorsrud — Fri, 14 Sep 2018 07:28:34 GMT

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

[quote user="dgerman0"]1) Why does flash via nrfjprog produce an unusable part?[/quote]

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.

[quote user="dgerman0"]PS It's not a "WARNING" if the application is not executed,
It's CRITICAL![/quote]

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.

[quote user="dgerman0"]2) Why is there a difference when using nrftools succeeds?[/quote]

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.

[quote user="dgerman0"]Do you need any additional information?[/quote]

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

RE: nrfjprog version: 9.7.3 fails nrftool success

dgerman — Thu, 13 Sep 2018 21:53:48 GMT

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?

RE: nrfjprog version: 9.7.3 fails nrftool success

Einar Thorsrud — Thu, 13 Sep 2018 12:37:10 GMT

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.