【GD32L233C-START Review】 Extra 1 Solution to download problems

yang_alex

【GD32L233C-START Review】 Extra 1 Solution to download problems [Copy link]

After compiling the program on the GD32L233C-START evaluation board, the following error message box pops up during downloading.

Oops! The program download was normal before, why not this time? Let's check it first.

After confirmation, the following error box pops up:

Unable to load the download algorithm file, of course the download will fail.

Why can't I load the downloaded algorithm file? I unplugged and plugged the download USB cable again, but it still didn't work. I switched back to the previous project, and it downloaded normally, indicating that it was not a hardware problem. After struggling for a long time, I suddenly noticed the prompt in the compilation output box:

"Insufficient RAM for Flash Algorithms" Insufficient RAM space for FLASH algorithms! I suddenly remembered that when the internal FLASH of the MCU was relatively small, it might be burning while transferring data (really just like writing FLASHRAM, one-to-one correspondence between address and write code data). When the FLASH is relatively large, the burning algorithm is first downloaded to the internal RAM of the MCU (the burning algorithm of FLASH itself is equivalent to a small program, which is placed inside the chip for execution during the process of burning the program to FLASHRAM by the burner or debugger. The running speed of SRAM is faster than FLASHRAM, so it is often placed on SRAM, so the burning algorithm needs to allocate memory space during the burning process), and then a cache is opened on the RAM, and the burning data is downloaded from the PC while burning (FLASHRAM writing is relatively slow) (during the waiting time for FLASHRAM writing). So this fault is related to the size of RAM allocation when the MCU burns the code.

Sure enough, increase the RAM used to download the algorithm in the figure below:

The fault is resolved.

Here is a question: why is this configuration data not bound to the device model? In the burning algorithm, when the burning device model is determined, the RAM of this MCU can also be determined. Before, when the SDRAM and FLASHRAM were external, it could be said that the size of the FLASHRAM on the user's single board was unknown, but now it is built-in, and knowing the device model can definitely confirm the size of RAM and FLASHRAM!

Jacktang

The RAM allocation size needs to be adjusted to allow the FLASH algorithm code to have enough RAM space.

Thanks for sharing

wadeRen

The purpose of doing this is probably to limit the RAM size when there is a need. For example, aRAM is used for this purpose, and bRAM is used for that purpose. It is similar to specifying the ROM size in the "Target" column. Even if you change it to 0x2000, it is still smaller than the actual size.

wangerxian

The download algorithm is so large? It shouldn't be.

yang_alex

During the process of burning the program to FLASHRAM by the burner or debugger, it is executed inside the chip. SRAM runs faster than FLASHRAM, so it is often placed on SRAM. Therefore, the burning algorithm needs to allocate memory space during the burning process), and then a cache is opened on RAM. While burning (FLASHRAM writing is relatively slow), the burning data is downloaded from the PC (during the FLASHRAM write waiting time).

There are two things mentioned here: one is the code of the burning algorithm, and the other is the code to be burned in (of course, it may not be transferred all at once, but in several times. The size of the code transferred at a time determines the size of the cache space in RAM, which is specified by the burning algorithm). Both of them need to be placed in RAM, so 0X1000 may not be enough.