DM365 Spi_norflash No operating system boot and Sys_bios boot (ii)

Four: The second start of the experiment (light LED, lighting program into the DDR)

The experiment was also tested by the light test, but this time it was to put the lighting program into the DDR, this experiment should pay attention to several problems:

1: The lighting section of the code into the DDR, through the #pragmaCODE_SECTION (test, "DDR");

2: Due to the lighting program stored in the DDR, but the DSP can only be activated in the film in the process of automatic import, so the DDR procedures in the import need to manually write in the first paragraph stored in the film program. So this experiment will have 2 bin file import, the first is after the DSP on the electricity automatically from the Flsah into the film, the second is the need to manually import.

3: In the program to initialize the Pll,ddr,pinmux. Since the code for the lighting section is stored on the DDR, the program starts with a DDR clock, initializes it, and configures the SPI,SPI initialization in Pinmux, and then imports the lighting program stored in Flash into the DDR to perform the lighting procedure.

4:bin file generation, because the boot code is stored in the slice, but the lighting program is stored in the DDR, so you can not use the first experimental method of the bin file generation, the following provides two additional methods:

A: The Save memory function in CCS is exported directly from the first address and size of the two-segment 2-in-slice and DDR in the. map file, saved as two bin files.

B: First into the hex file, and then the slice, DDR on the corresponding code hex into 2 files, and then use the Hex2bin tool to convert to 2 bin files. Five: The third start of the experiment (light LED, lighting program alone into a project to start, cut the project code data all into the DDR)

This experiment is a separate creation of a light led project, and the original project is only responsible for the lighting of the environment of the LED configuration and program guidance, so that the first project to truly achieve the bootloader function. And the problem to be noted in this experiment is:

1: The implementation of the jump between two projects:

Uint32gentrypoint = 0x80000000;//The entry address of the second project

appentry= (void(*) (void)) Gentrypoint;//ubl ends, handing the entry address of the second project to Appentry

(*appentry) Transfer to a second project

2: The program jumps to the second project's Jump entry address for the second project's _c_int00 () function address.

Six: The fourth time starts the experiment (lights up the LED, the lighting procedure realizes under the Sys/bios system)

After the third two engineering experiments, you can see that this way of start-up in the two projects jump to achieve the starting mode is achievable, so the fourth experiment to the second project to the Sys/bios under the lighting procedure. The following are some of the problems encountered during debugging:

1: Work mode of the problem, first to introduce ARM's 7 working mode:

A, user mode (user): The execution mode of the normal program.

B, fast interrupt mode (FIQ): For high-speed data transfer and channel processing.

C, external interrupt mode (IRQ): For normal external interrupt handling.

D, privileged mode (SVE): Also called management mode, for the operating system to use a protection mode.

E, data access abort mode (ABT): for virtual storage and storage protection.

F, undefined Directive abort mode (UND): A coprocessor used to support the adoption of software policy hardware.

G, System mode (SYS): An operating system task that is used to run a privileged level.

6 other processor modes other than user mode are called privileged mode. In these modes, the program can access all system resources, or it can switch the processor mode arbitrarily. Among them, in addition to system mode, the other 5 privileged modes are also known as exception modes. Most of the user programs run in user mode. At this point, the application is not able to access some system resources protected by the operating system. The application also cannot switch mode directly.

So in this case there are problems, because in the first UBL project arm automatically into the user mode, but in the Sys/bios mode arm into the system mode, but the user mode can not directly switch to the system mode, which will lead to the failure of the program jump, where the solution is, Skip the first two sentences of-c_int00 to change the arm's working mode instructions.