malloc failing

It is't clear what you mean.

Are the parameters (pointers) "para6" and "para7" getting incorrect values, i.e. pointing at the wrong locations.

Or are "para6" and "para7" pointing to the correct locations, but the memory locations have been changed?

We would really need to see both the code that makes use of "para6" and "para7" and the code that calls the function (after having made sure that the last two parameters do point to valid memory and that the memory do contain the expected values) to be able to be pout.

It is't clear what you mean.

Are the parameters (pointers) "para6" and "para7" getting incorrect values, i.e. pointing at the wrong locations.

Or are "para6" and "para7" pointing to the correct locations, but the memory locations have been changed?

We would really need to see both the code that makes use of "para6" and "para7" and the code that calls the function (after having made sure that the last two parameters do point to valid memory and that the memory do contain the expected values) to be able to be pout.

The memory they are pointing to is changed.
And there is no other code executed than the code to call the function.

I just made a test, I put all the parameters into a struct and the behavior is quite curious.

typedef struct
{
    Type_t1 *p_para1;
    int para2;
    float para3;
    float para4;
    int para5;
    int *para6;
    int *para7;

} function_params_t;

/* inside the calling function */
function_params_t params;

params.p_para1 = p_para1;
params.para2 = para2;
params.para3 = para3;
params.para4 = para4;
params.para5 = para5;
params.para6 = para6;
params.para7 = para7;

When this code is executed, the address where params is located (&params) changes!
What is happening?

If the variable "params" is a global variable, it should always have a fixed address.

If the variable "params" is an auto variable, the address will depend on the current stack depth when reaching the function that contains the variable.

But the variable should not move if you continue deeper in your call tree.

How do you deduce that the variable moves? Looking at a named variable in the debugger? Looking at the contents of an absolute address in the debugger? Some other method? Note that auto variables are often problematic for a debugger when you continue to call new functions, since the currrent stack frame gets replaced with the new stack frame for the called function. But looking at a memory dump for an absolute address should still show the contents of the "params" struct, unless "params" happens to be located in a position where it may either be overwritten by a DMA transfer, or may be damaged by a stack overflow.

I think the stack gets corrupted. When I make the variable global, this problem disappears - and others come up...

Something else to consider is the implications of having assembler-written ISR that fails to save one or more registers. Depending on what registers that gets trashed in the ISR, large parts of the main application can continue to work.

A x86 processor has quite few registers, so a corrupted register quickly kills a program. The ARM has a lot of registers so in some situations you can have large code blocks that rely on the contents of a specific register.

I do not have assembler written ISRs, all ISRs are written in C.

-> To exclude this as the reason, I may just disable all interrupts and try to run the program - right?

btw: Where does RTX place the stack of each task?

_I think_ there is a global container called 'mp_stk', unless the task provides its own memory. Look in your .map file.

In an RTOS environment, it is often hard to turn off interrupts, since the main goal of the application is to multitask.

I just found it in the sources of RTX.
There is memory defined with _declare_box8 and as you said, it's called mp_stk.

MicroLib + RTX + A function with 7 parameters.

It seams like the problem is solved.
I printf-ed the values inside the function and saw, that the values were right. So the debugger fooled me and showed me the wrong values.