[Taylor Heck]

This is equivalent, assuming you’re targeting an MDot:

multitool device plain -b -i MTDOT -c -o out_file.bin in_file.bin

The bootloader offset (0×10000) is handled by specifying the device series (MTDOT).

[Taylor Heck]

You can assume a message on port 201 with command ID 0x02 is a fragmentation setup request with the descriptor field and a message on port 201 with command ID 0x80 is a checksum response.

If the checksum response is incorrect the received file is deleted. Also, the checksum request is sent up to 3 times, if no response is received the file is deleted.

The Conduit does not send the file again.

[Taylor Heck]

What is the bootloader’s version?

Are you able to program the module with a dev kit instead of YMODEM?

[Taylor Heck]

Yes, that’s correct.

Offline you’ll get both a combined image and an application only image.

Images from the online compiler will have the bootloader combined and it will need to be stripped when upgrading over YMODEM.

[Taylor Heck]

With mbed-os 5 a post-build script combined bootloader and application into one image as well as appending a CRC. With mbed-os 6 this is no longer the case.

We have a Pyhton tool that can be used to append the CRC https://pypi.org/project/mtsmultitool

Also note that older MDot bootloader versions expected the firmware image to also have a bootloader included. The newer bootloader assumes the upgrade image does not include a bootloader.

The mbed-cli will output a *_application.bin image which should be used for YMODEM upgrades. The multitool program can be used to strip a bootloader from the image if needed.

Appending CRC:
> multitool device crc -o output.bin fw_application.bin

Strip bootloader and append CRC:
> multitool device plain -b 0x10000 -c -o outut.bin fw.bin

[Author]

Posts