EFM32-chip peripherals-Special Keil configuration of MSC

 

When you look at the functions in the MSC of EFM32, for example, when you look at the function MSC_ErasePage (), do you have to pay attention to a large part of the above explanation. The detailed English is as follows:

This function MUST be executed from RAM. failure to execute this portion of the code in RAM will result in a hardfault. for IAR, Rowley and Codesourcery this will be achieved automatically. for Keil uVision 4 you must define a section called "ram_code" and
Place this manually in your project's scatter file.

In general, this function must be executed in RAM. If it is not executed in RAM, a hardware error is interrupted, that is, Hardfault. If IAR, Rowley, and Codesourcery are used, this function is automatically executed in RAM. In Keil uVersion4, a segment called ram_code must be defined, and declare it in the scatter file of the project.

First, why can IAR be automatically executed in RAM?

1. IAR provides the _ ramfunc keyword, which automatically copies the function to RAM for execution. In efm32_msc.h, The MSC_ErasePage () function is defined as follows:

_ Ramfunc msc_Return_TypeDef MSC_ErasePage (uint32_t * startAddress );

2. Similarly, in Rowley, the definition is as follows:

Msc_Return_TypeDef MSC_ErasePage (uint32_t * startAddress) _ attribute _ (section (". fast ")));

3. Similarly, codesourcery is defined as follows:

Msc_return_typedef msc_erasepage (uint32_t * startaddress) _ attribute _ (Section (". Ram ")));

The three definitions are different, but all implement the effects of functions executed in Ram. You do not need to set this parameter.

In the current Keil version, it is troublesome. For example, if you want to perform operations on g stk, You need to modify the linker In the Keil project configuration. Example:

1. Cancel the use menory layout from target dialog Option

2. Select the custom. SCT file in the scatter file.

Next, let's take a look at what is defined in this file.

; **************************************** *********************
; *** Scatter-loading description file generated by uvision ***
; **************************************** *********************

Lr_irom1 0x00000000 0x00020000 {; load region size_region
Er_irom1 0x00000000 0x00020000 {; load address = Execution address
*. O (reset, + first)
* (Inroot $ sections)
. ANY (+ RO)
}
RW_IRAM1 0x20000000 0x00004000 {; RW data
. ANY (+ RW + ZI)
* (Ram_code)
}
}

It defines the ROM address and RAM address, but it defines another thing called ram_code. The ram_code defines the operation functions in the MSC into RAM.

You can copy this information, modify it based on your model, and save it as a. sct file. Then load it in through Keil.

But why should I copy it to RAM for execution? The reason is that Flash cannot be operated when Flash is erased. In addition, it takes some time to erase the Flash. In our function, we use code to read MSC-related registers and determine whether the operation is complete. Therefore, there is a paradox that you need to run the code to determine whether the code is complete or not, and you cannot run the code in Flash. Therefore, a solution is to run the code in RAM.