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.
62 byte data packets
So the default would be 20 byte packets? Thanks for finding the limit - that must have taken a while :) Sounds like there's not really a reason not to increase the MTU for the bootloader.
I never really 'got' the NRF debug stuff either, but I'm pretty sure it's expecting to use the UART.
send 8 and wait for response
Yeah, so in the old bootloader it was configurable, so setting to 8 was relatively sane.
What I do in secure DFU is I ask for a CRC after every 8 packets in order to basically fake what the old bootloader did. I'm completely ignoring the result of the CRC - it's literally just used to allow me to push 8 writes via Noble as fast as possible and then use the request/response to sync it all back up :)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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.
So the default would be 20 byte packets? Thanks for finding the limit - that must have taken a while :) Sounds like there's not really a reason not to increase the MTU for the bootloader.
I never really 'got' the NRF debug stuff either, but I'm pretty sure it's expecting to use the UART.
Yeah, so in the old bootloader it was configurable, so setting to 8 was relatively sane.
What I do in secure DFU is I ask for a CRC after every 8 packets in order to basically fake what the old bootloader did. I'm completely ignoring the result of the CRC - it's literally just used to allow me to push 8 writes via Noble as fast as possible and then use the request/response to sync it all back up :)