CODE AND STORAGE OVERLAP while building firmware for NRF52

Interesting is that when I write larger packets than 62 the bootloader completely freezes and device needs reset. So maybe there is some limit around 64 bytes but did not find it.

Started to look into having larger MTU again and found someone having exactly same issue with data over 62 bytes here https://devzone.nordicsemi.com/f/nordic-­q-a/16436/peripheral-fault-from-dle-with­-s132-v3-0 "My current issue is that when I call sd_ble_gattc_write() on the Central with more than 62 bytes, the Peripheral hits some fault before the application receives the event."

Looks like it it because of NRF_BLE_MAX_MTU_SIZE defined in wrong place, the ble_stack_handler_types.h in softdevice_handler needs it for defining correct size of BLE_STACK_EVT_MSG_BUF_SIZE so it was crashing there when it was not defined globally. And there is also NRF_BLE_GATT_MAX_MTU_SIZE (with GATT inside ) used too.

Anyway, managed to build Espruino with MTU of 59 for guys using P8 watch with those unicycles (as new ones has protocol based on 56 byte messages) and it seems to work just fine :-)
https://gist.github.com/freestyl3r/318cf­4b00a9287f5f452cab9d8b32ccd#file-espruin­o-js-L18

Even the memory requirements are not that bad, looks like enlarging MTU by x takes x*6 bytes of ram in current configuration so here it took (59-23)*6 = 216 extra bytes.

Pull request coming in next days, even managed to pass it to linker from board file so then it looks like adding just this to board file (and reduce variables by 216/16)

     'DEFINES+=-DNRF_BLE_GATT_MAX_MTU_SIZE=59­ -DNRF_BLE_MAX_MTU_SIZE=59',
     'LDFLAGS += -Xlinker --defsym=LD_APP_RAM_BASE=0x2d18', # 0x2c40+(59-23)*6

and larger MTU works (with few changes in bluetooth.c)

EDIT: put the patch here https://gist.github.com/fanoush/74c17abe­d6cfc809d153d76b6752e1f1
the bottom two changes are optional and are only about making APP_RAM_BASE public in process.env so one can set the LD_APP_RAM_BASE in board file a bit larger to be sure it boots fine and then read this and tune board config and then disable this code, not sure how to make it in a nice way, it modifies softdevice handler to make the value global.