2812 The Ultimate Perverted Strategy for Transferring Programs to Flash

fish001

2812 The Ultimate Perverted Strategy for Transferring Programs to Flash [Copy link]

2812, to make an audio processing system (just a few simple filters). The preliminary development has been basically completed today. Now, as a beginner, I will briefly disclose the entire development process of 2812, for two purposes: 1. For reference by 2812 players 2. To listen to your opinions, understand the defects in my development process, and update them. At the beginning, I downloaded a 30-day demo board of CCS for 2812, opened the example program, and compiled and debugged it. I found that the C program can run, but the assembly program cannot run. I must use the assembly program. After searching for a long time, I found that after loading the assembly program, I have to select the reset operation from the menu, and then the PC can point to the beginning of the code, that is, the starting address of FLASH 0x3d8000. (I have looked through the help, tutorial, quickstart, and didn’t see any instructions to reset first, which pissed me off). Then I learned the instructions and pseudo instructions of 2812 and wrote several filter programs. Then, the 30-day demo board CCS expired, and TMD uninstalled and reinstalled it but it didn't work (TI said, MD, do you think I'm mentally retarded!), then the 2812SDK evaluation board I ordered arrived. I used the CCS for 2812 on the evaluation board to call out the program I wrote earlier, but TMD didn't give me face from the beginning. When I loaded it, it said that there was space but it couldn't be written. I saw that it was flash space. CCS's own assembly example puts the code in the flash space! I had to modify the cmd file and rearrange the code. In this way, when I used the SDK to simulate again, my program had nothing to do with the flash space. All the code was placed in the H0 space, and the data was placed in the M0 and L0L1 spaces. In this way, McBSP, timer, comparer, PWM output, PIE configuration, PLL, CSM, WATCHDOG, PERIPHERAL CLOCK, etc. came one by one. There were many problems during the process, such as: the peripheral device registers could not be written (peripheral clock control register was not configured properly), PWM had no output (GPIO register was not configured properly), the interrupt could not be entered (the watchdog was not closed correctly, and the interrupt was reset by the watchdog before it came), and the interrupt could only be entered once (PIEACK register did not clear the corresponding interrupt flag in the interrupt). After adjusting the peripheral devices, the signal was connected, and the signal processing process was placed in the McBSP serial port receiving interrupt. My project was almost done. The next step was to port my program to flash so that the SDK could run without PC and CCS. First open the flash burning software: SDFlash on the SDK CD. Open a 2812 example and look at the project setting. It is not very clear. Anyway, burn it first, and then reset->flash. Open CCS and call out the flash space. It is good. The erased places are all 0xffff, and the burned places are all correctly implanted. I directly use the example in SDFlash and replace its burning file with my out file. It cannot be burned in. Because in my out file, all the program data is in SARAM. It seems that I need to modify the program, put the code data in flash, recompile, and generate out file. Burn it again, and it will be burned in. At first, the program runs incorrectly. I use CCS to track and find that the DSP program cannot write to the place in flash that I define as data segment. It seems that I can only write my own boot loader at the beginning of flash and move all the data in flash to M0 space. After doing this, SDK is separated from PC and CCS can run. But after I carefully checked the waveform with an oscilloscope, I found that the waveform is inaccurate, that is, it is not exactly the same as when running with CCS simulation (at this time, all the code data is in SARAM). After research, I found that when the program in flash is executed, even if the waiting cycle is set to the lowest and the flash pipeline is opened, it is not necessarily one cycle per instruction (for example: a string of nops, the execution is 1cycle, 1cycle, 1cycle, 4cycle, 1cycle, 1cycle, 1cycle, 4cycle...). This is unacceptable to my system. The code must also be moved to SARAM. But there is a problem in moving the code, that is, there are jump and call instructions in the code, and the jump and call go back to the flash. So I checked the instructions, and I changed all the jumps to short jumps with relative displacement, but there is no relative call, all are absolute address calls. Now, I have to use a perverted trick: first compile and load the version of the program that runs completely correctly (all the code and data are in SARAM) and reset it, then select the file menu -> data -> save, I save my program and data into hexadecimal text files respectively. That is, one line of machine code and data "0xXXXX". Then use Delphi to write a small program, add ".word" to each line of the two text files of code and data, so that these two text files become legal statements when added to the program used to burn the flash. Jump calls are definitely pointing to SARAM. Recompile to get the out file, and then burn the flash, this is completely correct. The SDK board is separated from the PC, CCS runs, and the waveform is also very accurate. But I think I must have done something wrong. TI can't let its users do such a perverted flash programming operation? Also note: When burning flash, the SDK jumper should be selected to boot to H0 ram, otherwise the programming may fail. This point is not mentioned in the TMD document help. When CCS is running without a PC, the SDK jumper should be selected to boot to H0 flash. The description may not be very clear, so please bear with it.