Optimization of generated code


I have osqp solver genrated code(MATLAB interface) and trying to build the code using TI tool chains. During memory allocation, my linker could not allocate the uninitialized global and static variables (.ebss) section. The reason is .ebss is of 70.866 KB and the available RAM is of 54 KB.

How can I reduce my uninitialized global variables?. Please let me know if is there any way to reduce my variables

Thanks and Regards,

What is the size of the problem you are generating the code for? Currently, the best way to reduce the memory footprint would be to reduce the problem size.

Hi Satheesh,

Could you tell us for which TI architecture you are trying to build OSQP? Are you compiling using CCS, makefiles or CMake?

You could try one or a combination of the following:

  • compile using floats instead of doubles
  • allocate certain arrays in external memory. you can use #pragma DATA_SECTION(var, mysection) to place some of the arrays defined in workspace.h in some section mysection. You should map mysection to the external memory in the linker command file. The largest and least used arrays would probably be csc Pdata in workspace.h, allocating the arrays of that structure in external memory shouldn’t penalize your performance much.

Please let us know about your workaround.

Thanks for the suggestions. I will try to do the changes and let you know.

  1. I am trying build OSQP for TI Delfino microcontroller (TMS320F28379D Dual core).
  2. I am compiling using CCS.

Thanks and Regards,

As you mentioned higher memory foot print is due to problem size.

I have a problem with prediction horizon of 200.
P = 602x602
q = 602x1
A = 1004x602
l = 1004x1
u = 1004x1

Thanks and Regards,

I assume that you are using the solver to solve an MPC type problem. Do you really need such a long horizon? If so, have you considered implementing a move blocking strategy to condense the problem slightly?

Hi paul,

  1. I am using solver for MPC type problem
  2. If I reduce my prediction horizon then in MATLAB interface solver is able to solve the problem with 25 interations but after code generation and executed on TI processor, solver is taking maximum iterations of 4000 but still solver status is -2
  3. I have implemented periodic receding horizon strategy which resulted in less memory footprint. But it also resulted in termination of solver after reaching maximum iterations after executing in TI processor


It is quite surprising that the solver should behave differently when used through the matlab interface and when used via embedded export. This makes me suspect that something basic is going wrong in your process for the TI target.

Have you tried solving a very simple problem in both places to check that the behaviour is actually the same? For example, I would suggest trying to solve the problem in osqp_demo.c on both platforms and checking that the iterates agree.

Hi paul,
I have tried with one simple problem in both matlab and TI processor. I could observe the same behaviour(Though Embedded processor is taking 15 seconds of time for 25 iterations).

prediction horizon = 100
P = 302x302
q = 302x1
A = 504x302 (sparse)
l = 504x1
u = 504x1

MATLAB output

TI processor output

Different behavior can be caused by:

  • EMBEDDED=1 option: it does not update the matrices and does not update \rho.
  • check_termination=0: it never checks termination and reaches the maximum number of iterations before checking convergence.
  • DFLOATS=ON: floating point numbers instead of doubles can increase the number of iterations.

Are you using any of these three options?

Unless I am misunderstanding something, it appears that your residuals are not even close to agreement between the two versions.

My suggestion was not to try a smaller version of your problem, but rather to try a problem if trivial size like in the osqp_demo. I suggest this because you need to exclude problems that are occurring due to mistranslation of the problem data when exporting.


  1. yes, I am using embedded = 1 by selecting the vectors as parameters. Reason behind this is the requirement of less memory footprint.
  2. check_termination is left as default i.e., 25.
  3. I am using of ‘double’ while generating the code.
    Here are my settings for code generation.

Hi paul,

I am trying to build the osqp_demo.c on TI processor.
But there is an error


If you have exported from a windows machine but then tried to compile on a different platform, you probably need to edit some of the generated headers. Most likely it is osqp_configure.h