Tag Archives: Embedded Road

(Keil MDK) UCOS floating point support abnormal solution

Recently, we encountered a problem, that is, the printf display of floating-point calls in uCOSII is abnormal, but the support for floating-point calls on bare metal machines is normal. Here are the details.

When calling printf to debug floating-point numbers in UCOS, it is correct in memory, but print data is 0, and other shaping data are normal.

The running result on bare metal is completely normal, that is to say, the problem lies in UCOS.

According to the information, this is because the user task stack is not aligned with octets. When running bare metal programs, the system’s default stack octets are aligned, but UCOS’s user task stack is not.

Align the user stack octets.

 

Solution:

1. Solutions under IAR: (untested)

Through # pragma data_ Alignment specifies the number of bytes to align

For example:


#pragma data_alignment=8

OS_STK Task1_LED1_Stk[Task1_LED1_Stk_Size];

#pragma data_alignment=8

OS_STK T

2. Solutions under keil MDK: (available for personal testing)

Add the force octet alignment command before the task stack declaration, as follows:

__align(8) static OS_STK  TaskEquipmentStk[TASK_EQUIPMENT_STK_SIZE];
__align(8) static OS_STK  TaskUartRcvStk[TASK_UARTRCV_STK_SIZE];
__align(8) static OS_STK  TaskFileRcvStk[TASK_FILERCV_STK_SIZE];
__align(8) static OS_STK  TaskFtpStk[ TASK_FTP_STK_SIZE ];
__align(8) static OS_STK  TaskErrorRateRS485Stk[ TASK_ERROR_RATE_RS485_STK_SIZE ];

 

Detailed explanation of the reasons

The history of this is that arm itself does not support non aligned data access; Therefore, with a 64bit data operation instruction, the instruction requires 8-byte alignment.

Furthermore, after a certain version of the compiler (rvct3?) AAPCs requires stack 8-byte alignment.

AAPCs with 8-byte alignment first, then cm3. Pay attention to the sequence. Before cm3 r2p0, automatic stack pressing does not require 8 alignment, and r2p0 seems to be forced alignment.

Printf’s 8-alignment is required by the C runtime and has nothing to do with hardware. The C RTL manual is written and can be read. Its root lies in the requirements of AAPCs; AAPCs is rooted in instructions like LDRD.

In other words, in the future, if 128bit data operation is available and arm does not support non alignment, AAPCs may be upgraded to 16 byte alignment.

Causes and solutions of errors in “insufficient ram for flash algorithms”

The error of “insufficient ram for flash algorithms” usually has a prompt window of “can’t load flash programming algorithm!” as shown in the following figure:
in case of “insufficient ram for flash algorithms” error, there will be a prompt window of “can’t load flash programming algorithm!”

“Insufficient ram for flash algorithms” literally means “insufficient RAM space for loading flash algorithm”.

This error usually occurs after adding a new flash burning algorithm.

Reason: the flash burning algorithm itself is also equivalent to a small program, which is executed by the chip in the process of burning program from JLINK to flash, so the burning algorithm needs to allocate memory space in the burning process. Open the settings of the utilities tab to see its configuration options;

As shown in the figure:

The place indicated by the arrow in the figure is the size of the RAM space for storing the burning algorithm. If the allocation of this place is too small, the above error message will be caused.

The problem can be solved by changing its size to a larger one.

For reference only.

If you want to reprint it, please note: the reasons and solutions for the errors in insufficientram for flash algorithms