Skip to main content
Visitor II
September 4, 2025
Question

Trying to receive large unknown size data over UART (over 1MB)

  • September 4, 2025
  • 2 replies
  • 479 views

So I am new to STM32 , what I want to implement is to receive large data(preferably over 1MB) which is greater than the size of receive buffer of UART so how should I proceed with it. Since the data I am receiving is in the form of hex, I also have to program the flash using the same data.

    This topic has been closed for replies.

    2 replies

    Super User
    September 4, 2025

    welcome to the forum.

    Please see How to write your question to maximize your chances to find a solution for best results.

     


    @Victorious wrote:

    I also have to program the flash using the same data.


    So are you trying to implement in-application firmware update (IAP)?

    If so, see Application note AN4657STM32 in-application programming (IAP) using the USART.

     

    The general principle is that you receive a block of data, program that to Flash, then receive the next block, etc, etc,...

    So you need some kind of "protocol" to tell the sender when the receiver is ready for the next block.

    The above-mentioned App Note uses YMODEM; other protocols, of course, are available.

     

    PS:

    If firmware update is the requirement here, note that you can also use the built-in bootloader - then you don't have to write any code yourself at all!

    See AN2606, Introduction to system memory boot mode on STM32 MCUs.

    Visitor II
    September 5, 2025

    Yes, I am trying to implement IAP. I did make my bootloader but it works only for file sizes that are small. I have heard about different techniques like ring buffer, double buffers etc to counter this problem but I have problem implementing them.

    Explorer
    September 5, 2025

    Fact is, you don't have enough resources (RAM) do receive the complete application firmware, so you need to do it piece by piece.

    A complete line of a Hex or S19 file for instance would be such a unit.
    Complicating side conditions are, you can erase Flash only per sector, and code execution from the same bank stalls while an erase/program is ongoing.

    But that aside, you would need to coordinate both sides, your bootloader and the host application to perform the update. An erase can take dozens or hundreds of milliseconds, flashing a short sequence takes several milliseconds. You might not be able to receive new data at that time, so you need to implement a stop/go mechanism.

    And you might choose to erase the whole (main application) Flash , or erase sectors ad hoc when you need to reflash them.

    And perhaps add a plausibility check to avoid killing the bootloader, persistent data, or accessing non-existent Flash.

    Super User
    September 4, 2025

    Data is sent byte by byte. When you receive some amount of bytes, do what you want with it and be ready to receive more.

    Putting the UART in circular receive mode with DMA will generally be best here. Use the half-transfer and full-transfer complete callbacks to process those halves of the buffer.

    Ensure programming can complete before the next half of the buffer is ready. Look at the data sheet for flash programming times and use the UART baud rate to calculate how long you have.

    Visitor II
    September 5, 2025

    I dont need more bytes after I have received the unknown number of bytes once(lets say in this case 1MB). You could say I am uploading Intel Hex File whose size would differ depending upon the application.