TMS570LS3134: Floating point issue

The FPU on Hercules MCU is ARM Vector Floating Point v3 architecture, with 16 double-precision registers (VFPv3D16).

In the project property, please select VFPv3D16  --> --float_support=VFPv3D16

Sachin Edwin said:

This happens for both fpu settings i.e. fpu=none and fpu= configured to use internal processor. 

Can you clarify which compiler is used?

Mention of the fpu option suggests you might be using the GNU GCC compiler.

Hi Wang,

Example code:

f32_value = (f32_ActValue * 1000) + f32_offset;

where, f32_ActValue = 18.66610

f32_offset = 0.0f

The output that I should get is 18666.10

When the --fpu==none, the output value sometimes outputs 37.3444 or 348.4344.

With the above setting, when I check the assembly code I see __aeabi_fmul and __aeabi_add library is used which is from GCC I guess.

When --fpu==VFPv3D16, the output is 0.0 sometimes 

With the above setting, when I check the assembly code I see internal processor instructions are used.

So with both settings I get different values, which I am not able to explain.

I use IAR compiler v6.40 

Hi Chester,

I use IAR compiler V6.40 

Example code:

f32_value = (f32_ActValue * 1000) + f32_offset;

where, f32_ActValue = 18.66610

f32_offset = 0.0f

The output that I should get is 18666.10

When the --fpu==none, the output value sometimes outputs 37.3444 or 348.4344.

With the above setting, when I check the assembly code I see __aeabi_fmul and __aeabi_add library is used which is from GCC I guess.

When --fpu==VFPv3D16, the output is 0.0 sometimes 

With the above setting, when I check the assembly code I see internal processor instructions are used

Sachin Edwin said:

At the point of floating calculations I disable all interrupts and enable them back again, this seems to work.

Something behind interrupts which causes the value to be calculated wrong. 

My initial thought was that interrupts were using floating point registers, but the floating point context wasn't being saved by the interrupt handler.

Sachin Edwin said:

This happens for both fpu settings i.e. fpu=none and fpu= configured to use internal processor. 

However, since the failure still occurs when using fpu=none then don't believe the issue is explained by interrupt handlers using floating point registers without saving the floating point context.

Is your program bare-metal, or does it use any OS such as FreeRTOS?

Hi Chester,

The OS used is Sciopta RTOS.https://www.sciopta.com/wip/products/index.html

Sachin Edwin said:

The OS used is Sciopta RTOS

OK, this is the first time have seen Sciopta RTOS.

From quickly looking at SCIOPTA Kernel Manual some thoughts are:

1. Section 2.10 Error Handling contains:

The kernel will detect if messages and stacks have been over written beyond its length.

Are any of the Kernel error checks failing?

2. Section 4.63.6 Structure Members Common for all Process Types indicates there is a fpu field in the Process Descriptor Block (PDB) which indicates if the process uses floating point or not. What is the fpu field set to?

While not clear what the fpu field does to Sciopta RTOS guess that controls if the floating point content is saved on a content switch. I.e. a process using floating point but with the fpu field set to SC_KRN_FLAG_FALSE in the PDB could potentially lead to corruption.

Chester Gillon said:

1. Section 2.10 Error Handling contains:

The kernel will detect if messages and stacks have been over written beyond its length.

Are any of the Kernel error checks failing?

A: I can confirm that there are no kernel error checks failing

Chester Gillon said:

2. Section 4.63.6 Structure Members Common for all Process Types indicates there is a fpu field in the Process Descriptor Block (PDB) which indicates if the process uses floating point or not. What is the fpu field set to?

A: we are not using this FPU field in any of our processes

Hi Sachin,

Have you solved the FPU issue?