Colleagues.
I recently implemented Proprietary code readout protection (PCROP) according to AN4758 on the STM32G473CEU MCU in IAR v.9.50.1. The project I was protecting was quite large and did not fit into one flash bank.
As soon as the project no longer fit into the first bank, I had to do a full chip clear via CubeProgrammer before each upload.
Otherwise, IAR would return an error. And if I uploaded short programs, the error did not occur.
Accordingly, a full chip clear kills the protected constant area, which significantly changes the brilliant concept of end-user file updates. In addition, the command line in the Build Action menu
"$TOOLKIT_DIR$\bin\isymexport.exe" --edit "$PROJ_DIR$\steering_file.txt" "$TARGET_PATH$" "$PROJ_DIR$\fir_filter.o"
creates the fir_filter.o symbol definition file from the file with the same name at level N, according to the steering_file.txt file.
So the fir_filter.o file at level N also needs to be passed to the end user and included in the IAR project tree.
In addition, I encountered the fact that the flash write of the first bank in interrupt mode is different from that of the second bank.
The construction that worked perfectly in the first bank
while (ROM_Addr < Addr_ROM_End)
{
HAL_FLASH_Program_IT((uint32_t)FLASH_TYPEPROGRAM_DOUBLEWORD, (uint64_t)ROM_Addr, (uint64_t)*RAM_Addr);
while (pFlash.Address != (uint32_t)ROM_Addr) {}
ROM_Addr++;
RAM_Addr++;
}
I had to replace it with
HAL_FLASH_Program_IT((uint32_t)FLASH_TYPEPROGRAM_DOUBLEWORD, (uint64_t)ROM_Addr, (uint64_t)*RAM_Addr);
while (pFlash.ProcedureOnGoing) {}
ROM_Addr++;
RAM_Addr++;
}
which doesn't really fit with interrupts.
My interrupt handler is entirely in CCMSRAM, and everything related to working with flash is in RAM, including stm32g4xx_hal_flash.c.
And if you load flash functions into CCMSRAM, the first bank stops working correctly.
The project works in the end, but not the way I would like.
I would be extremely grateful for advice on working with the second memory bank in IAR on this MCU.
