System Lockup with >15 prio 3 task about trampoline HOT 10 CLOSED

Hello Sven. Could you post the OIL file and the tpl_app_config.c file ?

from trampoline.

Hello,
I added a cast to uint8_t and now it seems to be fixed. It this correct patch ? Is it a bug or a feature ?
if ((uint8_t)(READY_LIST(ready_list)[1].key) >

BR
Sven

from trampoline.

Hello Jean-Luc,
thank you very much for your lightning fast answer.
I will provide the files as requested by you.

One more comment:
The bubble up of the ready list seems to handle the negative key correctly.
Is the fact that the key gets negative the problem or is the handling of the negative key in the shown function the problem ?
What is the idea behind the fact that the priority key is a signed 8 bit integer and not a unsigned one ?
I even see in the code that there is an DOW_ASSERT right before the comparison, that is checking if the key is negative but it is cast it to uint32_t before, which mean it will always be positive and only in case the key is zero the ASSERT will fail. (The ASSERT is visible in the source window of my screenshot, but i guess it is disabled as i cannot see any assembly instructions that are representing the ASSERT)

One more addon:
The register values are and variables are all for real at the position.
It has compared r2 and r3 with the cmp r2,r3 instruction, which is FC and 1F, and the result is a N flag which means negative flag.
This will cause the next instruction, which is a ble to branch and avoid the preemption. It is treating the key FC as a negative number.

BR
Sven

from trampoline.

Hello Jean-Luc,
i put in the files.
debug.zip
I made a couple of tests. If I add top4 i get the problem, but if I use the same prio as the high tasks (prio 3) it is ok if I rebuild everything.
If I don't I also have the problem. I saw that the rank bit shift got changed from 5 bit to 4 bit with adding the additional task.
I guess the application was build with mixed setting and the rebuild was not proper.
BUT if I increase the prio of the top task from 3 to 4 and rebuild everything the problem is still there and I get the negative key.
BR
Sven Grundmann

from trampoline.

Hi Sven,

I checked the problem. First of all, the data type for tpl_priority had to be signed in the past but it appears that this restriction is no longer necessary. Moreover, if we consider a signed type, the number of bytes necessary to encode the priority is badly calculated in the templates. You have two options:

1. change the type for priority in templates/code/tpl_app_custom_types_h.goilTemplate, line 58, rather than casting in the kernel code, to an unsigned.
2. change the way the number of byte is computed. At line 1363 of root.goilTemplate you have:

let KEY_SIZE := [(1 << ([NUMBER_OF_PRIORITIES numberOfBits] +
                [MAX_JOBS_AMONG_PRIORITIES numberOfBits])) - 1 numberOfBytes]

It should be (but I did not test):

let KEY_SIZE := [(1 << ([NUMBER_OF_PRIORITIES numberOfBits] +
                [MAX_JOBS_AMONG_PRIORITIES numberOfBits] + 1)) - 1 numberOfBytes]

to take the sign bit into account.

Best regards

from trampoline.

Hello Jean-Luc,
thank you very much for the confirmation of the problem.

From my gut feeling I would fix it by using a unsigned 8 bit integer if the sign bit is not needed at all.
I think my trampoline version is m/o 2021 still.
I have also one software version of our software, that was upgraded to the latest git version of trampoline.

Do you know when the sign became obsolete ?
Was it already in my version from m/o 2021 or was it only recently ?

Will you also fix it in the github ?

BR
Sven Grundmann

from trampoline.

Hello Sven,

It became obsolete a long time ago. I would say around 2015.

I will fix it on GitHub.

Best regards

from trampoline.

Hello Jean-Luc,
I checked your comment and tried to fix the type from sint8 to uint8.
Unfortunately it is defined in custom app type header, which is autogenerated.
I tried to find the template, where it is generated, but I did't find it.
If you can point me to the file, I would prefer to fix the sint8 to uint8, instead of fixing the condition.

BR
Sven

from trampoline.

Hello Sven,

I commited the change yesterday: 61245ae

Best regards.

from trampoline.

Thank you. I will close the issue.

from trampoline.