scanf/printf not working when calling generated C code

In Matlab I have generated C code (.c/.h files) from a Matlab function using codegen from Matlab Coder.

I call this function in a while loop on an ARM quad-core Cortex A53 using AMD Vitis.

Before calling this function I use scanf/printf to get user input and to print to the serial monitor. However, scanf/printf only work once in the 1st iteration (before calling the function) and not in the 2nd iteration or later (after calling the function).

Is this a common problem and has anyone encountered this problem before?

I think, but am not sure, that the problem is in the generated C code and not in Vitis itself.

Thank you in advance!

[dpb]

What is the definition of failure to work here? What are the symptoms, specifically?

If you comment out the call to the function does the loop then run normally with whatever input/output being observed using scanf/printf? If so (and highly likely anyway) there's something wrong with the calling sequence or in the function itself. Without any other detail, it's not possible to say anything specific.

[Victor Lam]

Let's say the sequence of one iteration is: scanf + printf + function. In the 1st iteration it asks for user input and prints a message, but then the while loop runs forever without ever asking for user input or printing anything again in the 2nd iteration or later.

But if I comment out this function then in every iteration it always asks for user input and prints a message, as one would normally expect.

I used debugger mode to verify that the function has terminated and is not stuck. I also verified for specific inputs that the output of the function in C is identical to the Matlab function.

Does this behaviour occur more often or has anyone seen something like this before?

[dpb]

Probably no one has ever done precisely the same thing with the combination of environment and hardware so it's extremely likely the answer to that question is "No".

Knowing nothing of what the function does nor anything about the system you're running, it's unlikely anybody here can help.

If not calling the function removes the symptoms, then it is conclusive that something in either the calling/return linkage is broken or the function itself did something damaging outside returning its expected output(s). One next debugging step would be to create an empty null function in its stead and test calling it. If that is successful, then add the argument list alone, then the output arguments until find what step causes something to break. You could also try replacing the function call with something simple like timestwo.c and make sure the code generator can handle the simple case first. It's always possible there is something unique in the development environment it doesn't know about -- maybe a default convention assumed isn't the same as expected.

"... I use scanf/printf to get user input and to print to the serial monitor"

I would suspect that the serial connection got broken would be a fairly likely possibility...

If that doesn't uncover the problem, you'll probably have to submit the whole enchilada to Mathworks suppor.

[Victor Lam]

Thank you very much for your suggestions!

I commented out parts of the generated C function and using the debugger I found what part is causing the problem mentioned before.

The function does terminate succesfully as the debugger exits the function. However, with the debugger I found that the problem is that printf itself, which is called after the C function, gets stuck when printing the value of a variable. But when I print a fixed string without variables after this C function, then it never gets stuck.

Could this problem be caused by the values of a variable having the "wrong" value/format? Or that I am using the wrong format specifier (like '%d' or '%f')?

[dpb]

Aha! At least do have symptoms to research.

It's certainly possible there's a type mismatch but to say anything definitive would need to see both the snippet of MATLAB code with enough context to be able to verify variables and their types and then the resultant C code. Or, are you saying the printf is MATLAB code, not converted to C and so isn't the C runtime i/o library routine? If the latter, it would look like perhaps your C function isn't returning the same variable type as you are presuming it is. Again, we've got to be able to see what we're talking about...

[Victor Lam]

The printf is the one in C code and I think I found what the cause is of the problem. Here are the most important steps that cause printf to get stuck:

• obtain the variables cycles_before and cycles_after which are of type uint64_t
• define the variable clock_speed which is of type const double
• compute double CPU_time = cycles / clock_speed * 1e6;
• print the variable with printf("CPU time: %f us\n", CPU_time);

Hopefully, this makes it a bit more clear, let me know if you need more information!

[dpb]

Without the actual code, it's not possible to say anything definitive. The internal variable definitions and typing and possible conversions and how are retrieved/saved in memory and addressed in the calls are the critical points and cannot be determined explicitly without the code itself.

That a literal string does work and the floating point variable doesn't is pretty definite indication there's a mismatch in there somewhere between what is being passed and what the function prototype is expecting. It's possible there's a mismatch in the default floating point size type in the compiler flags other than inside the code itself, too, you need to confirm what the compiler is being told.

Again, "simplify, simplify"...can you write and successfully call a routine that does nothing but printf() a passed variable of varying type?

ADDENDUM

obtain the variables cycles_before and cycles_after which are of type uint64_t
define the variable clock_speed which is of type const double
compute double CPU_time = cycles / clock_speed * 1e6

may be an issue -- the integer divide will be integer -- need to promote those to doubles first I think.

[Victor Lam]

If I remove the C function, then printf always works, even if the data type is varying.

When I commented out everything in the C function and uncommented parts of the code step by step, I also noticed that for longer code I get the same problem but not for shorter code. So it might indeed be a memory problem.

I would like to share the code, but I am not sure if you can reproduce the problem without the hardware, which is an ARM quad-core Cortex A53. Maybe you can suggest some steps I can try to confirm that it is memory problem?

Thanks for your help so far!

[dpb]

Being able to read the specific code would let folks have at least a chance of spotting an issue -- keeping it hidden does nothing to help advance diagnosing a problem. If I understand correctly, the printf() call is inside the C function. What if you were to return the additional variables to do the timing calculation to the calling routine -- can you get them back correctly and then compute and print the result in the calling MATLAB code instead? That doesn't solve the underlying problem but would perhaps confirm or deny that the internals of the function are doing what is expected.

In the above pseudo code cycles isn't defined -- one presumes it is the difference between the prior two - _after - before which is also going to be uiint64 so there is that issue of mixed mode arithmetic which otomh I don't recall exactly how C handles -- but

c=uint64(pi*1E4)

c = uint64
31416

s=2E8;
t=c/s

t = uint64
0

t=c/s*1E6

t = uint64
0

with some just made up dummy numbers, MATLAB coerces to the integer type and the division is going to be integer -- here c<s so --> 0

[Victor Lam]

Actually printf() is in C code, and my problems are purely in C code using Vitis and running it on the ARM processor. Right now, there is no Matlab involved. Matlab was only used to generate the C function which is then called in Vitis.

The reason I asked on this forum is because the C function was generated in Matlab. Can I just post C code here as well? Also, since the code is part of my research I can share only parts of it.

When the debugger is stuck on printf() and I break it, then it goes into an infinite loop while(1) {;} in xil_exception.c, which is the reason why it gets stuck.

[dpb]

You can inline any code as text -- the code button won't know syntax formatting rules specific to C but it will leave the linefeeds and so will be as well formatted as the code generator managed to do for perusal.

As I noted in very first response the odds are not high anybody here is going to have any experience with the specific environment and processor so you might have better luck from that standpoint on a C-specirfic forum with somebody spotting bogus code.

I would again bring your attention to the mixed mode operations -- I suspect that's a good chance of being at least part of the issue. My guess from the behavior described is that the io runtime is looking and failing to find a null-terminated string which is the C way of terminating loops on string arrays. That would be consistent with the other described symptoms of a literal string working where the variable doesn't. My guess is either you are referencing a memory location of the variable as a const -- that is the value seen by the printf() argument is probably the value of the variable being treated as the address rather than the address although I don't recall otomh what the C io library function will do if send the uint8 to a '%f' format.although I think all numeric types are ok for it.

What if you just compile and run a main{} program that calls printf -- can you get that to work passing various types and then expand it to mimic other operations?

In short, I don't have a lot of faith that anybody will be able to spot something from the C code, but there's absolutely no chance of anything further without it.

[Victor Lam]

Okay, then maybe I try to ask on stackoverflow.com or on the AMD forum itself, because I think this is more Vitis/C specific.

Thank you very much for your help!