Send .bin file through UART

[RComa.1]

Hello, i am using a STM32L0xx series, i just finished my bootloader than can init and jump an application from the specific location in Flash memory, so the only thing left to do is getting bin file (data) from the usart, but how can i send a .bin file from the computer to MCU's usart?¿ i can send hexadecimals, decimals, text etc...but what about binary files?¿

The main idea is use a GPRS module (i have it already) and put the .bin file in a cloud and download it finally, but i don't know how to send this....

Thanks in advance

[TDK]

Get a USB to UART adapter, boot up your chip in bootloader mode, and use STM32CubeProgrammer in UART mode to program the device, if that's what you're wanting.

Most terminal programs have the ability to send raw data (e.g. a file) through the terminal. Data is data, it only becomes something after it's interpreted on the other side.

[RComa.1]

Hi, thanks but that's not what i mean, because you mean use the bootloader from the manufacturer...i codes my own bootloader...i want to do an OTA so i can use the UART to receive data from a cloud service

[Pavel A.]

Do you know about vintage file transfer protocols: YMODEM, ZMODEM and others?

This is how people send binary files for decades.

Many popular terminal apps support at least one of these.

Look for YMODEM examples in Cube packages.

But OTA from cloud... you need something else there, not a serial port.

[Tesla DeLorean · Accepted solution]

fwrite(binaryarray, sizeof(binaryarray), 1, fTTY); // ??

Data is Data. Problem is most seem to have skipped/avoided the whole "how is data represented in memory and files" topic.

Most probably package the data in some object form, providing size, address and other details.

Pushing a file as it's inherent data content in a way you can reconstruct it, X/Y-Modem protocols have been used for serial links, the popularity here coming from it being self pacing, and retry/recovery from data loss/corruption issues.

Pulling from a file server? HTTP GET tells you in the response header how big the subsequent blob of data is. Strong benefit here is that you don't need to engineer both ends of the connection, its a ubiquitous standard, frequently with modem side support, but even at a socket level its not very complicated.

If ASCII is easier to manage the .BIN could be formed as .HEX file sentences/lines, the resulting data transfer would look about 2.5x bigger in overall volume. You'd likely need some kind of flow control, as the data is likely to arrive faster than the write to flash can work.