You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
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.
@fanoush
Just a followup, I have recompiled espruino bootloader with larger MTU and after doing it almost right I found you already did it in your increased_mtu branch too :-)
BTW here you increased ORIGIN but kept the length. However when fixing it it did not build as the data+heap overflowed so I had to build bootloader with -D__HEAP_SIZE=0, then it would link fine (by default it reserves 0x2000 for heap).
Anyway, the bootloader still works after changes, so I modified the secure dfu method of python flasher to send larger data packets and it somehow works. The secure DFU design is more complicated than legacy one and is slower - with legacy you send all data and in the end there is one crc check. With secure there is additional level - instead of whole firmware you do the same but in 4096 (page size) chunks called objects which is crc checked and commited/executed separately. Anyway even with this overhead and 62 byte data packets there is speedup. I can do 2.8KB/s which is slower than legacy but still faster than before. 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. The only limits I founds is code here and it should be enough. I also tried to increase chunk count from 4 to 8 there but it does not help. The interesting piece handling the packet is here and I don't see why
p_req->req_lenbeing over 62 would be a problem an any code below it. Maybe stack overflow or some BLE issue? I don't have debug output from bootloader, how NRF debug log work, can it do serial or only some segger specific tracing stuff? Anyway, this is just FYI. No need for you to spend extra time on debugging this.BTW, thanks for mentioning the removed legacy dfu web bluetooth implementation, found it, that saves some time :-)
And as for "send 8 and wait for response" this is not hacky but normal(?) You initially send to bootloader how often you want notifications, with legacy you may even disable it completely. numbers over 10 are normal there. It it this and this but maybe you mean something different?