CODE AND STORAGE OVERLAP while building firmware for NRF52

Yes default here is 20. My current numbers with getting exactly one notification per each 4096 based object is 1 minute and 18 seconds when sending 263228 bytes of application. When I remove explicit CRC check command before committing/executing each block I am down to 1 minute and 12 seconds (=3655 bytes/s). So 6 seconds for extra crc checks would not be so bad, however the notification also contains crc check so if I set it to receive one notification right after sending each whole 4096 block I get crc check for for free, without needing to send any explicit CALC_CHECKSUM command.

my changes in python flasher for secure dfu procedure are here
the output looks like this

pi@raspberrypi:~/dsd6-ota-dfu-python $ ./dfu.py --secure -a CF:1E:35:40:14:92  -z espruino_2v04.187_dsd6_sdk12.zip 

    ================================
    ==                            ==
    ==         DFU Server         ==
    ==                            ==
    ================================
    
Sending file espruino_2v04.187_dsd6_sdk12_app.bin to CF:1E:35:40:14:92
Binary imge size: 263228
Binary CRC32: 1958051001
Connecting to CF:1E:35:40:14:92
Checking DFU State...
Init packet successfully transfered
MTU: 158, packet size: 62
Max object size: 4096, num objects: 65, offset: 0, total size: 263228
Progress: |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 100.0% Complete (263228 of 263228 bytes)

Upload complete in 1 minutes and 12 seconds
DFU Server done

And BTW, I finally understand relation between larger MTU and DLE - data length extension. They are not directly related. One can have larger MTU but no DLE. That is why iphone has MTU 158 or 185 so that it would fit in 6 or 7 classic 27 byte packets. So it is nice if there are larger packets via DLE and it fits in just one, but if DLE is not enabled, it is sent as set of packets hopefully in one connection interval.

That's great, thanks! Yeah, I thought usually ORIGIN+LENGTH should have contained all of RAM - didn't realise that they added heap on top. It's surprising the build didn't fail for me too.

It contains all of RAM, heap and stack is allocated inside it. You made RAM to be 0x9A48. But now when thinking about it, it worked fine because it was originally too small! It was below 0x8000=32KB before, but nrf52832 has 64KB which is 0x10000. In fact in normal espruino linker file here it is correct, 0x2c40+0xd3c0=0x10000. For bootloader it was previously 0x2C00+0x5380=0x7F80. So perhaps it was 32KB minus 0x80 space for bonding or some other info passed from application(?) Or is it intentional to have only 32KB for bootloader and leave the other 32KB for appliciation?