lbh00 ok this means also that using FOTA will work if we use this bootloader right ?
Yes! 
Is there a size limit for the app_update.bin using MCUboot?
This is a small size 192k for a real life application.
Will there be a support for a larger file ?
Regards
louis.h
lbh00 future updates may have a larger size. I’ll likely be getting back to that in the near future.
5 months later
Hello Jared,
I see there is Bootloader V2, does this one support larger files to update?
I am trying it but I am not successful…sometimes the download starts but stops and timeout …
Is there something special that I should do on my application during compilation to be compatible with this bootloader?
Thanks
lbh00 yes it supports larger sizes. You’ll need to load it using a J-Link (or similar). The hex is in the downloads section of the documentation site.
hello Jared,
thanks for your reply.
yes i used the downloaded file from your website and using J-link programmed the feather board.
I enter DFU mode and I see the blue LED turn ON.
However the download of an application firmware is failing after few kilobytes downloaded because of timeout…
what could be the issue?
lbh00 I suggest you update to the latest SDK if you can. V2 bootloader is only supported with NCS > 1.4x
Hello
I installed ncs version 1.5.0, but I still get the same behaviour.
i.e. timeout after the first 1-2 % downloaded.
How can one troubleshoot this ?
Regards
Can you flash this guy and see if it works?
Also, are you using LittleFS at all?
Hello,
no I am not using LittleFS.
I have used the proposed MCUboot provided in the link, now I am sometimes successful with the update, and some other times timeout occurs.
Note that both cases occur with the same application firmware files, and same MCUboot version.
Regards
- Edited
lbh00 can you confirm you don’t have a terminal session open in another tab/window? newtmgr will fail if you are connected to the serial port elsewhere.
Yes I can confirm,
Actually the timeout occurs while transferring the file most of the time.
Hello
I tried the -r3 option: retry 3 times as follows
newtmgr -r3 -c serial image upload build/zephyr/app_update.bin
and this works with a higher probability than with no -r option, I am thinking that maybe the high speed and cable combination is causing issues.
Can I use lower baud rates? I tried to change to baud=115200, but this did not work: the download was not even starting.
maybe some info about my setup would be helpful.
I am on a mac, with USB C connectors, so I have a USB hub(?) in order to have a USB A connector, than use USB A to USB mini cable.
I tried changing the cable but this did not help.
Hello Jared,
The image size will be about 700Kbytes eventually.
The -r3 option seem to be acceptable so far.
I will later on try a better usb cable to see if this helps or not.
Cheers
- Edited
lbh00 the size of your .bin? That’s huge. I’m not sure if the bootloader will be able to handle an application size that large.
Please keep me informed!
Hello,
The code is not yet final and we are testing different parts separately.
I will keep you posted.
What is the max file size MCUboot can handle? is it related to the flash size and the partitions of slot0 and slot1?
or are there other limitations ?
By the way I tried with bootloader V2 (supplied from your website) on another board and newtmgr did not timeout at all even without the -r3 option.
so it looks like something board specific on the connection level of the USB …