Embedded Coder Bug: Not using return value of code-generated "Prelookup" function

3 views (last 30 days)
I'm having an issue with some code generated by Embedded Coder. For some reason, my model's main loop calls the prelookup function plook_u32d_linckpag() but does not use the return value.
The function declaration is as follows:
extern uint32_T plook_u32d_linckpag(real_T u, const real_T bp[], uint32_T
maxIndex, uint32_T *prevIndex);
Has anyone seen behavior like this before?
While I'm here, I'm also seeing the model's main loop setting every element of an array to zero right before an if-statement that checks if one of these array elements is nonzero to execute another block of code.
Is this an artifact of optimization? I've tried debugging the Target Language Compiler but I don't think I'm getting anywhere.

Accepted Answer

Abhishek Kumar Singh
Abhishek Kumar Singh on 23 Feb 2024
Hi Gabriel,
Regarding the unused return value from the prelookup function, I assume you have already checked the model configuration, ensured the correct model setup, and also tried code generation with the 'Interpolation Using Prelookup' block. The most probable cause seems to be dead code elimination. The optimization process employed by Embedded Coder might have determined that the return value does not affect the program's behavior and thus removed its usage.
As for the issue of array initialization, there could be two reasons: either the Embedded Coder is initializing the array before entering the conditional logic for determinism reasons, or, as you suggested, it is an artifact of optimization. You can check the code generation settings related to initialization and data handling.
Investigating these points may help to pinpoint the problem. Of course, the nuances of each model can shed more light on such issues, making them easier to unravel.
  1 Comment
Gabriel Aaron
Gabriel Aaron on 23 Feb 2024
Edited: Walter Roberson on 23 Feb 2024
Hi Abhishek,
Thanks for your reply. I figured out a few days ago that this issue was due to Simulink parameters being modified in mask intialization functions and losing their tunability, leading to the in-lining of those variables in the generated code.
For anyone having the same issue, this was in 2023a and I found the following in the Simulink release notes for 2023b:
"Before R2023b, if a model contained blocks with mask initialization commands that modified a mask dialog parameter or created a new variable in the mask initialization, and if that parameter or variable is referenced in a child block, the values of the mask parameter or variable were in-lined in the generated code. The parameters were not tunable even if they referred to a workspace variable."
This documentation page might be helpful too (for 2023b+) https://www.mathworks.com/help/simulink/ug/preserve-tunability.html

Sign in to comment.

More Answers (0)


Find more on Deployment, Integration, and Supported Hardware in Help Center and File Exchange




Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!