• on the Android DFU app, I don't have DfuTarg option, but Bangle ECDB instead. Is it ok?

    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...hex file and see if right at the end the lines go :10DFE, :10DFF and 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-major on 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 :)

  • 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-update to compile the firmware and indeed at the end of bootloader...hex was this line :08E00C0011C30700C1C10700A8. After switching to the same compiler version as yours I got this line :08DFF40021C30700CDC10700A5 instead.

    I tested an was able to perform BLE DFU upgrade from version 2v04.264 to 2V04.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.

About

Avatar for Gordon @Gordon started