Wrong timing in sys_arch.c in function sys_arch_mbox_fetch (LwIP)

[Detlef-Bs]

Hallo,
I try to use LwIP with freertos. The sw was generated via CubeMX.
I have problems to get it running. So I did some investigations. I found some strange behavior of the overall timing.
DHCP retrys when failling getting the IP-address. But the time between retrys are very long.

The reason for this behavior seams to be a failure in
"STM32CubeFX/Middlewares/Third_Party/LwIP/system/OS/sys_arch.c, Release v1.16.0! in function "sys_arch_mbox_fetch".
It is the line 184
....
#else
status = osMessageQueueGet(*mbox, msg, 0, timeout);
if (status == osOK)
....
As mentioned in the description of the function the value timeout is [ms]. The caller of "sys_arch_mbox_fetch" uses [ms] as it seams to me.
But osMessageQueueGet expects [kernel-ticks] (CMSIS-RTOS2, RTOS V2).

As long as kernel-ticks has a length of 1ms everything works as expected. I thing CubeMx generates the default value 1ms.
But I changed the kernel-tick to 10ms; so the waiting time is 10 times of timeout.

A proposal for correction:

uint32_t const TickLength_ms = 1000 / osKernelGetTickFreq();
status = osMessageQueueGet( *mbox, msg, 0, timeout / TickLength_ms );

Thanks,
Detlef

[SofLit]

Hello @Detlef-Bs and welcome to the community,

I will escalate this internally for a proposal. Internal ticket number 198834.

Thank you for your contribution.

[Pavel A.]

> But I changed the kernel-tick to 10ms

Any reason for this?

[Detlef-Bs]

I don't need a very high tick-rate. 10ms is realy enough. So the CPU is not used so much for this kind of work.
From the point of view of freertos this should not be a problem.
I have done this in the past often to get good balance in using the CPU. Using the CPU for the operating only as much as it is realy needed for the application.

Meanwhile I have seen that the whole LwIP seams to depend on a fixed 1ms timer.
It builds own internal sw-timers upon this 1ms timer. LwIP get tick-numbers; but don't calculate the time in ms.
May be there are other features depending on this 1ms timer?

[Pavel A.]

> May be there are other features depending on this 1ms timer?

May be.