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.