I have to admit the problem here is pretty hard to diagnose. The problem actually traces back to the definitions of A and B:
[A,B,C,D] = tf2ss(num, denum);
After this call, codegen thinks A is :2-by-:2 and B is :2-by-:1. This is because we have
>> [A,B,C,D] = tf2ss(1,[1,1,1]); size(A), size(B)
ans =
2 2
ans =
2 1
>> [A,B,C,D] = tf2ss(1,[0,1,1]); size(A), size(B)
ans =
1 1
ans =
1 1
>> [A,B,C,D] = tf2ss(1,[0,0,1]); size(A), size(B)
ans =
0 0
ans =
0 0
But the assumption built into the rest of the program is clearly just the first case, so I assume that we know for certain that m is nonzero, A is 2-by-2, and B is 2-by-1. Codegen isn't so sure. All it knows is that A is :2-by-:2 and B is :2-by-:1. It also knows that inside sys x is 2-by-1 and t is scalar, hence u3I is scalar. I guess the problem theoretically occurs if A were 1-by-2 and B were 2-by-0, then A*x is scalar, and B*u3I is 2-by-0. Consequently, A*x + B*u3I is 2-by-0, which is not a column vector. That can't happen, but codegen doesn't know this.
There are multiple ways of fixing this. One way is to add the coder.noImplicitExpansionInFunction declaration to sys:
function dx = sys(t, x, u)
coder.noImplicitExpansionInFunction;
%interpolate the data set (ts,u3) at time t
u3I = interp1(ts, u, t);
dx = A*x + B*u3I;
end
I think that works because by turning off implicit expansion, you also eliminate support for run-time scalar expansion, so the codegen will require and enforce that A*x and B*u3I have the same number of rows and columns (because they are added).
If that seems too mysterious, you can fix it where B is used:
function dx = sys(t, x, u)
%interpolate the data set (ts,u3) at time t
u3I = interp1(ts, u, t);
dx = A*x + B(:,1)*u3I;
end
My recommendation, however is to fix it where B is defined:
[Atmp,Btmp,C,D] = tf2ss(num, denum);
A = Atmp(1:2,1:2);
B = Btmp(1:2,1);
because now A and B are fixed in size. That should generate better code.
