DFU on custom board, memory problem

RE: DFU on custom board, memory problem

Fikri Saman — Tue, 07 Jul 2020 12:00:56 GMT

Alright. Thanks either way for your help. I appreciate it alot 😁

RE: DFU on custom board, memory problem

Edvin — Tue, 07 Jul 2020 11:55:50 GMT

Then there is not enough space to run on the small chip. I am sorry. You need to use the big version, or use a smaller application and an older SDK that has a smaller bootloader. There is nothing more we can do about this.

RE: DFU on custom board, memory problem

Fikri Saman — Tue, 07 Jul 2020 08:10:47 GMT

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258633"]try running this on a DK with full flash and RAM[/quote]

I ran the original bootloader (PCA10040E S112 debug) on my nRF52832 DK and it was working well. Though I am not sure what you mean by full flash and RAM but here is what the memory layout looks like :

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258633"] What trouble are you actually having?[/quote]

I flashed the PCA10040E debug version that I modified to use S132 on my DK and this is the memory layout :

It seems to me that there is not enough space for my main application. Here is what I got when I tried to DFU my main application :

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0003F000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0003F000, lending 0
ding 0
<info> nrf_dfu_settings: Backing up settings page to address 0x3E000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0003E000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0003E000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x0003E000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0003E000, src=0x20007ACC, len=896 bytes), queue usage: 1
ding 0
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00031000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...
<debug> app: Enter main loop
<debug> nrf_dfu_ble: Connected
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 6
<debug> nrf_dfu_ble: min_conn_interval: 6
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 500
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600
<debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 517, reply: 247).
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST.
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (251, max_rx_time 2120).
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_ble: Set receipt notif
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_RECEIPT_NOTIF_SET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
<debug> app: timer_stop (0x20005984)
<debug> app: timer_activate (0x20005984)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_ble: Buffer 0x200066B0 acquired, len 141 (244)
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
<debug> nrf_dfu_ble: Freeing buffer 0x200066B0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
<debug> nrf_dfu_validation: PB: Init packet data len: 64
<info> nrf_dfu_validation: Signature required. Checking signature.
<info> nrf_dfu_validation: Calculating hash (len: 64)
<info> nrf_dfu_validation: Verify signature
<info> nrf_dfu_validation: Image verified
<debug> app: Enter nrf_dfu_cache_prepare()
<debug> app: required_size: 0x9268.
<debug> app: single_bank: false.
<debug> app: keep_app: false.
<debug> app: pass: 0.
<debug> app: cache_address: 0x26000.
<debug> app: cache_too_small: true.
<debug> app: keep_firmware: false.
<debug> app: delete_more: true.
<debug> app: pass: 1.
<debug> app: cache_address: 0x26000.
<debug> app: cache_too_small: true.
<debug> app: keep_firmware: true.
0x4
<warning> nrf_dfu_ble: DFU request 4 failed with error: 0x4
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 6
<debug> nrf_dfu_ble: min_conn_interval: 6
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 500
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600

RE: DFU on custom board, memory problem

Edvin — Mon, 06 Jul 2020 14:18:23 GMT

We are really short staffed in support due to summer holidays. Can you please try running this on a DK with full flash and RAM to make sure that everything else is working before you take on the smaller variant?

Some of it is probably because of the increased RAM by the softdevice yes.

[quote user="Fikri Saman"]I was able to compile and build the project. I also managed to flash it on my custom board. But the placement of the bootloader will cause some trouble.[/quote]

What trouble are you actually having?

RE: DFU on custom board, memory problem

Fikri Saman — Mon, 06 Jul 2020 13:58:48 GMT

With the following configurations, the bootloader used up about 35.4kB of RAM, which does not leave me enough space for my application :

FLASH_PH_START=0x0 
FLASH_PH_SIZE=0x40000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x10000
FLASH_START=0x31000
FLASH_SIZE=0x6000
RAM_START=0x20005968
RAM_SIZE=0xa698

Flash placement :

devzone.nordicsemi.com/.../3326.flash_5F00_placement.xml

Before any changes were made, it only uses, as you said, 20kB of RAM. Is it because due to the changing of softdevice that causes it to increase?

RE: DFU on custom board, memory problem

Edvin — Mon, 06 Jul 2020 13:25:33 GMT

Oh, I didn't catch that it was a separate issue. So where did you want to place the bootloader? Did you try to move it to where you want it? Looks like you can move it something like 0x9000 up. Did you try to do so?

RE: DFU on custom board, memory problem

Fikri Saman — Mon, 06 Jul 2020 11:43:49 GMT

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258580"]Do you use the S132 as a requirement?[/quote]

Yes, since my application uses s132

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258580"]I assume it is the S132, but what version?[/quote]

Version 7.0.1.

I already solved the problem with the softdevice version check. My current problem is having to change my bootloader starting address to later accommodate my application.

RE: DFU on custom board, memory problem

Edvin — Mon, 06 Jul 2020 11:37:45 GMT

[quote user="Edvin Holmseth"][/quote]

Looks like the softdevice version check failed. Do you use the S132 as a requirement? What --sd-req did you use when you generated the packet, and what softdevice did you flash on your device? I assume it is the S132, but what version?

Have you tried to debug to see where in sd_req_check() it fails?

RE: DFU on custom board, memory problem

Fikri Saman — Mon, 06 Jul 2020 10:22:49 GMT

I'm using s132 v7.0.1. I did some modifications to the PCA10040e bootloader's configuration :

I changed the Memory Segments :

FLASH RX 0x0 0x40000;RAM RWX 0x20000000 0x8000;uicr_bootloader_start_address RX 0x10001014 0x4;bootloader_settings_page RX 0x0003F000 0x1000;uicr_mbr_params_page RX 0x10001018 0x4;mbr_params_page RX 0x0003E000 0x1000

I changed the Section Placement Macros :

FLASH_PH_START=0x0 
FLASH_PH_SIZE=0x40000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x28000
FLASH_SIZE=0x6000
RAM_START=0x20002ad8
RAM_SIZE=0xa698

I changed the softdevice in the loader to s132 v7.0.1
I changed the Target Device to nRF52832_xxAA
Register Definition File to ../../../../../modules/nrfx/mdk/nrf52832.svd

I was able to compile and build the project. I also managed to flash it on my custom board. But the placement of the bootloader will cause some trouble. Here what the memory layout looks like :

I don't know I tried to change the FLASH_START to 0x3DF90 but end up getting some errors.

RE: DFU on custom board, memory problem

Edvin — Mon, 06 Jul 2020 09:50:11 GMT

Have you tried to debug to see where in sd_req_check() it fails?

BR,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Thu, 02 Jul 2020 13:42:42 GMT

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258096"]However, I suspect that you will run into some issues. Looking at the placement of the files, it looks like there is not enough RAM to run your application:[/quote]

Yes, you are correct. I got these errors :

..
<warning> app: Aborting. Cannot fit new firmware on device
<error> nrf_dfu_validation: Can't find room for update
..

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/258096"]Alternatively, see if you can port the pca10040e bootloader project. It only uses 20kB of RAM, but you need to change it to using the S132 if that is what you are using.[/quote]

I'm not sure if my porting was correct, but here is what I did. I changed s112 to s132 in Code->Preprocessor->Preprocessor Definitions. Then I changed the header files in User Include Directories :

../../../../../components/softdevice/s132/headers
../../../../../components/softdevice/s132/headers/nrf52

I flashed and did a debug session on the bootloader, tried to update it with the main application got the following problem :

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0002F000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002F000, len=1 pages), queue usage: 0
<debug> nrf_dfu_flash: Flash erase success: addr=0x0002F000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0002F000, src=0x200040AC, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0002F000, pending 0
<info> nrf_dfu_settings: Backing up settings page to address 0x2E000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0002E000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002E000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x0002E000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0002E000, src=0x2000442C, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0002E000, pending 0
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<debug> app: timer_stop (0x200022E4)
<debug> app: timer_activate (0x200022E4)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00022000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_ble: BLE DFU transport initialized.
<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
<debug> app: Enter main loop
<debug> nrf_dfu_ble: Connected
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 6
<debug> nrf_dfu_ble: min_conn_interval: 6
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 500
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600
<debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 517, reply: 247).
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_ble: Set receipt notif
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_RECEIPT_NOTIF_SET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
<debug> app: timer_stop (0x200022E4)
<debug> app: timer_activate (0x200022E4)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_ble: Buffer 0x20003010 acquired, len 141 (244)
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
<debug> nrf_dfu_ble: Freeing buffer 0x20003010
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
<debug> nrf_dfu_validation: PB: Init packet data len: 64
<info> nrf_dfu_validation: Signature required. Checking signature.
<info> nrf_dfu_validation: Calculating hash (len: 64)
<info> nrf_dfu_validation: Verify signature
<info> nrf_dfu_validation: Image verified
<warning> nrf_dfu_ver_validation: SD req not met.
<warning> nrf_dfu_validation: Prevalidation failed.
<debug> nrf_dfu_validation: Init command:
<debug> nrf_dfu_validation:  08 00 10 34 1A 02 CB 01|...4....
<debug> nrf_dfu_validation:  20 00 28 00 30 00 38 E8| .(.0.8.
<debug> nrf_dfu_validation:  A4 02 42 24 08 03 12 20|..B$... 
<debug> nrf_dfu_validation:  A1 A0 1E 6C 6E 4B 18 64|...lnK.d
<debug> nrf_dfu_validation:  19 B2 A3 53 3F C0 4C 84|...S?.L.
<debug> nrf_dfu_validation:  0F 04 F1 15 A0 DD 21 2B|......!+
<debug> nrf_dfu_validation:  15 92 BB 11 6B AB DF DB|....k...
<debug> nrf_dfu_validation:  48 00 52 04 08 01 12 00|H.R.....
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0xB
<warning> nrf_dfu_ble: DFU request 4 failed with error: 0xB
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 6
<debug> nrf_dfu_ble: min_conn_interval: 6
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 500
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> nrf_dfu_ble: max_conn_interval: 12
<debug> nrf_dfu_ble: min_conn_interval: 12
<debug> nrf_dfu_ble: slave_latency: 0
<debug> nrf_dfu_ble: conn_sup_timeout: 600

RE: DFU on custom board, memory problem

Edvin — Thu, 02 Jul 2020 12:26:01 GMT

devzone.nordicsemi.com/.../pca10040_5F00_s132_5F00_ble_5F00_debug_5F00_256k.zip

Try this one. I did not change anything but the three things I mentioned in the previous reply. flash_placement.xml, build->memory segments, and linker->Section placement macros.

In SES it is possible to attach the debugger if the .hex file is already flashed. Try to do this. To do so, try to use (toolbar->) Target -> Attach Debugger. If you do this, SES will not program anything.

However, I suspect that you will run into some issues. Looking at the placement of the files, it looks like there is not enough RAM to run your application:

The application uses 42.4kB RAM, and your nRF52 only has 32kB. This is the case for the previous (non _debug) project I sent as well. It uses 33.8kB (close, but still more than 32kB.

It looks like the bootloader from SDK16 is too large for the 256/32 variant of the nRF52832.

Perhaps you should consider moving to the 512/64 version?

Alternatively, see if you can port the pca10040e bootloader project. It only uses 20kB of RAM, but you need to change it to using the S132 if that is what you are using.

BR,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Thu, 02 Jul 2020 07:40:02 GMT

Here are my Section Placement Macros :

My flash_placement.xml :

devzone.nordicsemi.com/.../0272.flash_5F00_placement.xml

My memory segments :

FLASH RX 0x0 0x40000;RAM RWX 0x20000000 0x8000;uicr_bootloader_start_address RX 0x10001014 0x4;bootloader_settings_page RX 0x0003F000 0x1000;uicr_mbr_params_page RX 0x10001018 0x4;mbr_params_page RX 0x0003E000 0x1000

They are all the same as the ones you sent me before and yet I still have these errors :

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/257825"]Does it contain an LFXTAL?[/quote]

Yes, it does contain an LFXTAL.

Concerning the debug session, if I run a debug session, wouldn't it erase the current program on my custom board? And which program do I have to run the debug session since there are the bootloader and the main application on my custom board

RE: DFU on custom board, memory problem

Edvin — Wed, 01 Jul 2020 12:16:58 GMT

[quote user="Fikri Saman"]I modified the bootloader_debug with the settings that you sent me before and got the following errors :[/quote]

What does your flash_placement.xml look like? And what does your project settings->Code->build->memory Segments setting look like? And what does your project settings->Code->linker->Section Placement Macros look like?

And for the two last ones, remember to select "Common" before checking them:

[quote user="Fikri Saman"]I don't think I understand what you're demanding. Are you asking about my custom board or the equipment I used to program my custom board?[/quote]

I am asking about your custom board. Does it contain an LFXTAL? That would be the X2 in this figure:

To run a debug session:

If you set NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0 in sdk_config, you will get the RTT output in Segger Embedded Studio.

Best regards,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Wed, 01 Jul 2020 09:37:24 GMT

I modified the bootloader_debug with the settings that you sent me before and got the following errors :

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/257593"]Does this mean that you are doing a debug session in SES, or that you only close RTT viewer opened externally?[/quote]

I actually don't know how to debug the bootloader via SES, that's why I used RTT viewer. It would be nice if you could point me in the right direction to debug with SES, please.

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/257593"]What is your clock configuration by the way? Do you have an external LFXTAL? I don't think I asked what kind of HW you are running this on.[/quote]

I don't think I understand what you're demanding. Are you asking about my custom board or the equipment I used to program my custom board?

RE: DFU on custom board, memory problem

Edvin — Tue, 30 Jun 2020 13:10:07 GMT

Hello,

Yes, you would have to modify the project settings. Look at the settings found in the project that I sent.

[quote user="Fikri Saman"]I also have another weird remark. With the previous application, if I don't have RTT Viewer on, it will not update successfully. But when I have RTT Viewer to see the log, it succeeds in doing the DFU. Is that normal?[/quote]

Does this mean that you are doing a debug session in SES, or that you only close RTT viewer opened externally?

The RTT viewer itself shouldn't matter, but if you run a debug session, that may affect the CLOCK. What is your clock configuration by the way? Do you have an external LFXTAL? I don't think I asked what kind of HW you are running this on.

BR,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Tue, 30 Jun 2020 08:23:06 GMT

For the debug bootloader, do I have to modify the section placement macros like in the example that you provided me?

I also have another weird remark. With the previous application, if I don't have RTT Viewer on, it will not update successfully. But when I have RTT Viewer to see the log, it succeeds in doing the DFU. Is that normal?

RE: DFU on custom board, memory problem

Edvin — Fri, 26 Jun 2020 10:52:09 GMT

Is it possible to flash the debug bootloader(s) instead of the normal bootloader and monitor the logging information? From your log, it just looks like it is in the middle of the process, but the nRF stops responding, and the connection times out.

Can you test this on a "normal" nRF52832 DK, and see if the problem may be related to the flash size?

Does this only happen after you read out the flash and reflash it? Or does it happen if you flash the bootloader and softdevice separately as well?

RE: DFU on custom board, memory problem

Fikri Saman — Fri, 26 Jun 2020 07:39:44 GMT

Well, nevermind. I was mistaken. It worked as in, I managed to see it advertising after reflashing it but the DFU does not seem to be working. I managed to enter into boot mode but it failed to update it when. This was the log file :

devzone.nordicsemi.com/.../Log_5F00_2020_2D00_06_2D00_26_5F00_09_5F00_33_5F00_51_5B00_1_5D00_.txt

RE: DFU on custom board, memory problem

Fikri Saman — Fri, 26 Jun 2020 06:57:12 GMT

Yes! It's working! Thank you very much, Edvin!

RE: DFU on custom board, memory problem

Edvin — Thu, 25 Jun 2020 13:52:01 GMT

The colouring in nRF Connect isn't ideal. It is basically an educated guess on where the bootloader is located, where the softdevice is and so on. Don't worry about that.

[quote user="Fikri Saman"]Then I tried to save it as a hex file and try to reflash it via nrfjprog but it didn't work. Here what it looks like :[/quote]

Did you remember to reset the device after reprogramming it? "nrfjprog --reset", since the reset button doesn't work until the first reset after programming it. Alternatively, power cycle the board.

BR,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Thu, 25 Jun 2020 12:38:41 GMT

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/256872"]Try "build and debug" and see what happens[/quote]

Nothing much to be honest. It seems to be working. I verified it via nRF Connect mobile and I see my board advertising DFUTARG.

This was the memory layout :

So instinctively, I try to update it with my application and it worked. Here is the memory :

Then I tried to save it as a hex file and try to reflash it via nrfjprog but it didn't work. Here what it looks like :

It seems that the extracted code doesn't recognize which part represents what.

Ideally, I would prefer to program my board in one go instead of programming the bootloader first, then generate my application zip file which then needs to be transferred to my phone, and only then I can update my board with the desired app.

RE: DFU on custom board, memory problem

Edvin — Thu, 25 Jun 2020 10:56:28 GMT

It looks like there is not enough RAM on the 256 version to run on the nRF52832 with 256KB flash and 32kB ram. Perhaps you should consider going for the nRF52832 with more flash and ram, or use an older SDK with a smaller space requirement.

You will probably see that you run into some issue if you run a debug session with the bootloader that I attached earlier. Try "build and debug" and see what happens. Remember to hit F5 to run the bootloader. What does it say?

BR,

Edvin

RE: DFU on custom board, memory problem

Fikri Saman — Thu, 25 Jun 2020 10:19:37 GMT

[quote userid="26071" url="~/f/nordic-q-a/62932/dfu-on-custom-board-memory-problem/256852"]Can you please try to check what the memory looks like on nRF Connect for Desktop -> Programmer when you do this?[/quote]

This is what the memory looks like when I flash only the bootloader with default memory settings on it :

It would seem that there is only the softdevice but yet I can see DFUTarg on nRF Connect mobile.

This is when I used your bootloader alongside with my application :

But it still seems not to be working. I cannot see my device on nRF Connect mobile. This is only with the bootloader that you provided :

I did see DFUTarg, and so I try to update it with my application but it failed to do so. This was the log file during the update :

devzone.nordicsemi.com/.../Log_5F00_2020_2D00_06_2D00_25_5F00_12_5F00_15_5F00_19_5B00_1_5D00_.txt

RE: DFU on custom board, memory problem

Edvin — Thu, 25 Jun 2020 09:26:39 GMT

[quote user="Fikri Saman"]A weird remark I notice was, I flashed my custom board with the bootloader with the default setting as shown in the following image :[/quote]

Can you please try to check what the memory looks like on nRF Connect for Desktop -> Programmer when you do this?

I did some modifications, and I got this:

(remember that my DK has 512kB flash, which is why it is gret on the upper half.)

Check out the attached project. NB: I only changed the SES project, not the Keil, IAR or armgcc.

devzone.nordicsemi.com/.../pca10040_5F00_s132_5F00_ble_5F00_256k.zip

There were some issues. I didn't manage to set the RAM size to 32kb, because the compiler complained about not enough space. I am not sure whether it will run properly on the 256k - 32k version. Perhaps the softdevice has grown too big to properly support this version in the later SDKs.

Best regards,

Edvin