-
The bootloader is ridiculously tight (due to the SDK11 layout it has to fit in less RAM than a normal SDK12 bootloader, plus it has to have an LCD driver). Even using the wrong compiler would have that effect. I'm using 8-2018-q4-major on mine and it fits with only about 8 bytes to spare.
Indeed, tried yesteday and for me it is just three bytes. There is a check in the makefile for size so it could be reduced to 7a000-7dfff area to catch this and fail. In fact I had my own modifications there for other devices and had to build from scratch since even one added line made it too big. BTW I think you could disable bootloader and app version checking that prevents downgrade here to save few bytes.
-
Thank you so much Gordon for helping me. The reason DFU mode was failing was exactly the one you anticipated.
I was using arm-none-eabi-gcc version
8-2019-q3-updateto compile the firmware and indeed at the end ofbootloader...hexwas this line:08E00C0011C30700C1C10700A8. After switching to the same compiler version as yours I got this line:08DFF40021C30700CDC10700A5instead.I tested an was able to perform BLE DFU upgrade from version
2v04.264to2V04.271.Thank you again for your reactivity and your willingness to help.
Finding a way to get a few more bytes out of the bootloader is definitely out of my reach. But I wish to contribute by filing bug reports and sharing small apps with the community.
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
fanoush
sebi
@Gordon
That's odd - if you started the scan before you entered bootloader mode then that might explain it.
@sebi thanks for letting me know - the fact you built your own narrows it down a lot :)
I don't really want to get involved in supporting this too much as I need to focus my time on getting the KickStarter Bangles out. BUT...
Looks to me like the bootloader is there (as it's displaying the bootloader text), but is corrupt. This sounds like the compiler you're using is generating a bootloader binary that is too big to fit in the available memory area. It means the bootloader will get the end cut off, and will probably work well enough to boot Espruino, but not enough to actually be a bootloader.
You could check the
bootloader...hexfile and see if right at the end the lines go:10DFE,:10DFFand THEN:xxE00. That'll mean it's running into the next page.The bootloader is ridiculously tight (due to the SDK11 layout it has to fit in less RAM than a normal SDK12 bootloader, plus it has to have an LCD driver). Even using the wrong compiler would have that effect. I'm using
8-2018-q4-majoron mine and it fits with only about 8 bytes to spare.If you or anyone else can find a way to get a few more bytes free in the bootloader it'd be hugely appreciated :)