DSP/BIOS getting a glimpse of the door path-ticking clock and burning Flash

DSP/BIOS getting a glimpse of the door path-ticking clock and burning Flash
Operating platform and environment DSP model: TMS320C6713
Simulator: XDS510PLUS
Flash model: Both AM29LV800BT and AM29LV800BT have been tried (the general interface is the same, but the difference is not big)
RAM model: MT48LC16M16A2P (pay attention to the 16-Bit Data Line Interface)
DSP/BIOS Library: V5.31.02
CSL Library: (assuming the reader is already using) write the LED program and talk about the OS tick clock.

In the last article on the basis of the use of DSP-BIOS entry, here with DSP/BIOS operating system CLK and PRD module, these two modules involve hardware timer, we use the simulator to first enable the LED flashing program on RAM.

CLK function: manages on-chip timer. All those who have learned about ARM know the tick clock. CLK is the tick clock of DSP OS!

All those who have learned the operating system know that (of course, there are not a few who do not know the operating system in their current schools): the operating system must provide a time base for scheduling! This time base is provided by the tick clock (PC is no exception, and sometimes the base ).

However, C6713 does not have a dedicated tick clock module. Therefore, it is triggered by a general Timer on the DSP. The interrupt function is the Timer interrupt function. For example, you need to set the tick clock to 1 ms, the attributes can be set as follows:

The Timer0 tick clock is configured above. Note that Microseconds indicates us and Millisecond indicates ms!

From the above configuration, we can also see that Timer0's CPU Interrupt number (CPU Interrupt) is HWI_INT14. Let's go to HWI (Hardware Interrupt module) to see if it is,

In CLK, the Timer is configured as the tick clock, and the tick interrupt function (also the Timer0 interrupt function) is fixed. Here it is CLK_F_isr and cannot be modified!

Exercise: Try configuring other Timer in CLK and check the hardware interruption changes in HWI? Answer: The Timer interrupt configured in CLK is associated with the Timer interrupt in HWI.

Well, let's write back the LED program. Let's write the simplest one -- to make an LED flash and use the tick clock, the interval is 1 s.

Isn't the tick Clock 1 ms? How to Implement 1 s timing? In this case, we have to understand a module-the cyclic function PDR. The trigger of PDR is based on a multiple of the tick clock period. PRD is a special software interrupt (you can check that there is a soft interrupt of PDR_swi under the SWI module), which is different from CLK, CLK is implemented by hardware Timer interruption.

As shown in, after you select Use CLK Manager to drive PDR, the CLK cycle count is used to trigger PDR. We insert a PDR object LedLink_PDR. The configuration attributes are as follows,

Since the tick-Answer clock CLK is 1 ms, Period indicates the number of tick-Answer clock times (ticks), so the cycle of LedLink_PDR is 1 ms * 1000 = 1000 ms = 1 s, this achieves the goal of timing 1 s. We then implement the above (soft) interrupt function LedLink in the. c file,

# Include "bios_firstcfg.h" # include <csl. h> // CSL library header file # include <csl_gpio.h> // CSL library's GPIO header file static GPIO_Handle hGpio; int main (void) {CSL_init (); hGpio = GPIO_open (GPIO_DEV0, middleware); GPIO_reset (hGpio); middleware (hGpio, middleware); middleware (hGpio, GPIO_PIN3, GPIO_OUTPUT); GPIO_pinWrite (hGpio, GPIO_PIN3, 0); LOG_enable (& trace ); LOG_printf (& trace, "Hello DSP/BIOS % d. ", 0); return 0;} void LedLink (void) {static Uint16 I = 0; I = (I + 1) & 0x01; GPIO_pinWrite (hGpio, GPIO_PIN3, I );}

To build a basic BIOS project based on the previous article DSP-BIOS getting started, func_task0, func_task1 and swi_adc are the previous article in the DSP/BIOS use task and Soft Interrupt routines, here is actually nothing to use, temporarily.

To run on hardware, you must set it in Global Setting,

In addition, the hardware -- GPIO_PIN3 is connected to the LED on my board, and the light is low! The cmd file is automatically configured in the DSP/BIOS configuration file. Mount the simulator and download it to the RAM of the Board! OK, success!

DSP/BIOS Operating System Startup Process

In fact, the startup process of DSP/BIOS has been mentioned in the previous article. Here, let's take a look:

System power-on reset. After the Flash program is loaded, it will be executed from the C/C ++ environment portal _ c_int00.
Use the. cinit record to initialize the. bss segment
Call BIOS_init to initialize various modules
Processing the. pinit table, such as the Global object constructor in C ++, is executed at this time.
Enter main function execution
The main function returns and calls BIOS_start to start the DSP/BIOS operating system.

In fact, apart from the Guiding Significance of step 1 for Flash writing, other steps are irrelevant (of course, only for the issues discussed here ). Based on this, the idea of writing Flash here is: after the system is reset, the program will jump to _ c_init00 and write a piece of code from the Flash copy application to the memory!

Flash burning for migration to the Operating System

In the previous article "general method for Flash writing on TMS320C6713", we have elaborated on how to burn bare metal code. Here we only need to make few changes to the DSP/BIOS project, the previous burning method can be seamlessly used here. The following is a step-by-step description of some different places (which is clearer ):

Add the files (3) used by the second-level Bootloader to the project, for example,

Check whether the copy_done function in the boot_c671x.s62 file is as follows:

copy_done:    mvkl .S2 _c_int00,b0    mvkh .S2 _c_int00,b0    b    .S2 b0    nop   5

Instead:

copy_done:    mvkl .S2 _main,b0    mvkh .S2 _main,b0    b    .S2 b0    nop   5

Because we need to first copy the code from Flash to the memory, and then execute c_int00 to jump to the main function.

Download three bootloader files here! If the RAM or Flash you are using is different from mine, modify the register configuration of The EMIF interface in c6713_emif.s62!

Divide Memory and set "segments"

This is based on the bare metal memory division method in the general method for Flash writing on TMS320C6713,

MEMORY{    BOOT_RAM   : o=00000000h,l=00000400h    IRAM       : o=00000400h,l=00040000h    FLASH_BOOT : o=90000000h,l=00000400h    FLASH_REST : o=90000400h,l=000FFB00h}

Heap is placed on IRAM.

For example, the general method for Flash writing based on "TMS320C6713" is also assigned by the cmd in. Most of them are allocated to IRAM, which is not prone to problems (although more RAM is used ).

Write the cmd file (user. cmd, for example)

The DSP/BIOS has automatically generated a CMD file. It is recommended that you do not modify it. You only need to Remove the automatically generated DSP/BIOS from the project (not delete it, But Remove it ), create one by yourself and include the DSP/BIOS,

-lbios_firstcfg.cmd-lcsl6713.libSECTIONS{        /* RAM */    .boot_load: {} > BOOT_RAM    /* User defined */  }

-Lbios_firstcfg.cmd automatically includes the generated one. The key is to add the. boot_load segment, which is specially used to place the second-level Bootloader. Include user. cmd in the project.

Modify DSP/BIOS reset interrupt

In "general method for Flash writing on TMS320C6713", the vecs. s Assembly file was modified to reset the original vector.

vectors:vector0:   VEC_ENTRY _c_int00    ;RESETvector1:   VEC_ENTRY _vec_dummy  ;NMIvector2:   VEC_ENTRY _vec_dummy  ;RSVD

Changed

vectors:vector0:   VEC_ENTRY _boot       ;RESETvector1:   VEC_ENTRY _vec_dummy  ;NMIvector2:   VEC_ENTRY _vec_dummy  ;RSVD

The same is true here, but it can be directly modified through IDE,

Here _ boot is the boot segment of the second-level Bootloader file boot_c671x.s62.

Well, there's nothing to do. You can compile it, and then follow the "general method of Flash burning in TMS320C6713" to complete the burning.

Give yourself some advice

Still in 1 ~ Two months ago, I still knew nothing about DSP Flash and DSP/BIOS. Then I downloaded ten papers from the Internet, I read this article one by one. Although I cannot understand it all at once, I still feel a little bit more sporadic, and then I am ready to write it myself, but I found that there was nowhere to start-those papers were all about the framework! It cannot meet the needs of beginners.

So I want to find some simple ones like Google/Baidu langtaosha on the Internet, especially the detailed steps provided in almost every step. Unfortunately, nothing is done! Later I thought about it. After a few days, I still don't know where to start. So I went to TI's manual for level-2 Bootloader at http://www.ti.com.cn/lit/an/spra999a/spra999a.small. (The Manual is very short, and even dozens of 20 pages. TI's Manual provides the second-level boot source code and describes the reasons and processes for doing so. Then, based on the relevant information provided in this manual, I pieced together the Bootloader process! The key is to work hard between the _ c_int00 and the main function.

Later, I started to write it by referring to TI's document, but the Startup File is well written, but how to burn it into Flash has been bothering me. If I burn it in the same program as the application, isn't that the question of "chicken or egg? (In fact, this can be set through an external dial switch on the hardware, so that the program can be self-written ). However, I did not turn it off. I consulted a Daniel from a QQ group. Daniel gave me a method of his burning and writing, and suddenly became very cheerful, after the DSP program is opened, everything that runs in the memory is read first. Is it okay to burn the program through another project? This is what I did last. In this process, I am still glad that I still know about the cmd file and memory, even changing the exported items from memory to header files also uses VIM (god-like editor ). I learned about DSP/BIOS. I'm glad that I have used uCOS ii before and will soon get started. The so-called "hate less when books are used", of course, I know its charm.

Some netizens have read my article titled "general method for Flash writing on TMS320C6713", so they asked me:

"Why can't I directly copy the assembly in the past ?"

Then, I replied:

"Can you go back and see what the Assembly is doing ?"

Answer:

"Assembly is too complicated. Let's explain why ."

Well, I really don't know how to persuade him. I only have a deep understanding of the functions implemented by the Assembly and the entire startup process (the process of code execution/Redirection ), in order to ensure that no matter how the hardware changes, how the environment changes, can be correctly written!

The IT industry has always had such a point of view:

"This code is available and can be used. You don't have to repeat the wheel !"

That's right. Unfortunately, I used the wrong part. I can only say:

"The wheel is ready, but is it easy? Are you sure you want to run it for ten days or eight days ?"

Once it becomes a standard, you do not need to duplicate the wheel. Otherwise, "continuous improvement" is the source of creation!