Problem description: DSP physically integrates program space and data space into a 4M*16-bit space. However, when implementing the FFT algorithm on it, the amount of computing data is too large and the internal RAM is insufficient. In this case, it is necessary to implement it through external SRAM expansion.
Note: In nonBIOS mode, there are only three CMD files: 28335_RAM_lnk.cmd (for simulation debugging), DSP2833x_Headers_nonBIOS.cmd, and F28335.cmd (for flash programming). Only the first two are used for simulation debugging, and only the last two are used for flash programming. In any mode, 28335_RAM_lnk.cmd and F28335.cmd cannot be used at the same time or in place of each other.
Usually we add two CMD files: 28335_RAM_lnk.cmd and DSP28335x_headers_nonBIOS.cmd.
I don't quite understand the red part: After the program is burned into FLASH, the speed at which the program runs in FLASH is determined by the speed at which the FLASH is read. If there is no FLASH acceleration technology, it is generally necessary to set a waiting time (XBANK.bit.BCYC?). In order to run the program at high speed, it is generally necessary to expand at least one SRAM to run the DSP algorithm at high speed.
The following is the specific process of expanding SRAM (tested):
ps: The number of sampling points N of FFT before expansion is 256, and the number of sampling points N of FFT after expansion can be 2048.
At first, I commented out the statement of expanding to ZONE7 in the CMD file, and debug reported an error: error #10099-D: program will not fit into available memory. run placement with alignment/blocking fails for section ".ebss" size 0x5064 page 1. Available memory ranges:, which means that there is not enough memory in RAML4.
Then remove the comments and add the statement in the red box in the figure below to the main file to compile the array with larger memory into the segment defined in CMD. After debugging, the program will not report an error, only a warning. At this time, the number of data points N=2048.
Postscript: What is written above is a bit simple. Actually, at the beginning, I tried to transplant the reversal function Rander() and the butterfly operation function Iterative_FFT() to Zone7, that is, to transplant the code rather than the data. However, the attempt failed and the error message was still insufficient memory in RAML4. I thought about it for a long time and considered that although the two functions were transplanted to Zone7, the data memory overhead generated by calling the two functions in main is still provided by RAML4, so an error message is still reported. Does anyone know?
Attached is the code for program transplantation:
First create a section in the SECTION of the CMD file:
xintffuncs: LOAD RAML4,
RUN ZONE7A,
LOAD_START(_XintffuncsLoadStart),
LOAD_END(_XintffuncsLoadEnd),
RUN_START(_XinffuncsRunStart),
PAGE = 0
2. Declare in the main file:
#pragam CODE_SECTION(Rander,"xintffuncs");
#pragma CODE_SECTION(Iterative,"xintffuncs");
|