cancel
Showing results for 
Search instead for 
Did you mean: 

Write Flash memory over virtual Com Port (USB)

Semiory
Associate II

Hello, I am developing a dual processor application with a host (STM32F205xx) and a slave (Radio Module SoC). The idea is to update the wireless module's firmware from the PC via the virtual COM port.
The firmware is temporarily stored in STM flash memory. The problem is that only the first segment is saved correctly. Attempting to save the next segment to flash memory will cause the Virtaul Com port to reboot.

When USB data reception interruption, the function below is called, the flash address was set to 0x080E0000 (will be cleared when STM restarts)

uint8_t ReceiveSegmentClb(const uint32_t offset, uint8_t *segmentData, uint8_t chunkSize)
{
    if(offset + chunkSize <= FirmwareLength)
    {
    uint8_t chunkIndex = 0;
    HAL_FLASH_Unlock();
    while(chunkIndex < chunkSize)
    {
       flashStatus = HAL_FLASH_Program(FLASH_TYPEPROGRAM_BYTE,
       0x080E0000 +offset + chunkIndex), segmentData[chunkIndex]);
       if(flashStatus != HAL_OK)
      {
         return -1:
         break;
      }
      chunkIndex++;
  }
  HAL_FLASH_Lock();
}
return 0;
}
After the ReceiveSegmentClb function is executed, the CDC_Transmit_HS(functionStatus, 1); shall be called.

Semiory_0-1694441426331.png

As can be seen from the image above, the first write was successful. On the PC side, the response comes correctly, but the next segment write cannot be started because the STM restarts itself.

What am I doing wrong?
Thanks in advance!!!



1 ACCEPTED SOLUTION

Accepted Solutions

Thanks for the advice, I checked the transmission chain and... I made a stupid mistake, I tried to write packets (via USB) that were larger than 64 bytes, which caused the internal logic to collapse. The FSM has interpreted the next data part not as a part of previous data transfer, but as a command to "reset" the STM...

View solution in original post

3 REPLIES 3
TDK
Guru

Look at the RCC->CSR flags on startup to determine the cause of the reset.

If that doesn't help, I'd recommend separating USB from the flash write. Try to write the new bootloader with dummy data and see if that works or triggers the reset. If it works, problem is likely in program handling or USB or some other program logic error.

If you feel a post has answered your question, please click "Accept as Solution".

Is it possible that your processor only has one bank of FLASH? I'm pretty sure that you can't write to the FLASH that you are running from. 

Check your map file and make sure that you aren't trying to erase a block (1 second per block) in the same FLASH bank that you are running from.

For me, I'd load the data into RAM rather than FLASH. Perhaps smaller blocks, but RAM is intended to be overwritten a zillion times, FLASH has a really short life if you erase/write it a bunch, especially with data that you have no intention of saving.

Thanks for the advice, I checked the transmission chain and... I made a stupid mistake, I tried to write packets (via USB) that were larger than 64 bytes, which caused the internal logic to collapse. The FSM has interpreted the next data part not as a part of previous data transfer, but as a command to "reset" the STM...