F28M35H52C: fprintf stops working after CPU reset.

Hello user,

this looks like a case of 'my program is working when I load from debugger, but doesn't work when I try to run it from reset'. We would need to do some debug to get you help with the problem.

One thing you mentioned about .cio section using the boot ROM reserved memory, I believe you fixed this. Yes no part of the application should have any anything assumed to be initialized correctly in the boot ROM reserved memory. Application can re-purpose this part of RAM but coming out of reset the boot ROM on device uses this RAM for boot so no initialized constants will be available.

Secondly, when you first target connect and load code onto C28x your applications with fprintf works fine, does it work fine after you do a debugger reset and restart on C28, without having to re-load the project?

Next thing I want to make sure that we alienate the problem to fprintf inclusion, can you check if this problem happens only if your application uses fprintf, if you don't use fprintf or try with a simple blinky/loop code on C28 you don't have this problem?

Best Regards

Santosh Athuru

"One thing you mentioned about .cio section using the boot ROM reserved memory, I believe you fixed this. Yes no part of the application should have any anything assumed to be initialized correctly in the boot ROM reserved memory. Application can re-purpose this part of RAM but coming out of reset the boot ROM on device uses this RAM for boot so no initialized constants will be available."

Yes, I have seen the .map file and there is no problem with this.

"Secondly, when you first target connect and load code onto C28x your applications with fprintf works fine, does it work fine after you do a debugger reset and restart on C28, without having to re-load the project?"

That is exactly what I have done and it did not work (after reseting and restarting from the debugger, of course, the first time I execute it, it does what I expect perfectly).

"Next thing I want to make sure that we alienate the problem to fprintf inclusion, can you check if this problem happens only if your application uses fprintf, if you don't use fprintf or try with a simple blinky/loop code on C28 you don't have this problem?"

That is right, I do not have any problem if, for example, I comment out the function that uses the fprintf.

Hello user,
thanks for confirming the above.

You mentioned that the application doesn't work, once it hits fprintf() after reset->restart->run. I'm assuming that after reset and restart, the program control reaches main() and you are able to step through the code till it reaches fprintf() and that is where you see the error.

one thing I forgot to ask or didn't see, is that the fail occurs at the first fprintf() or fail occurs after a few?

What happens if you do a program re-load after you hit reset ? below steps:
1> reset
2> program re-load
3> reset
4> restart
5> run (does it execute any fprintf()s and fail after a few?)

What happens in below sequence, second time after you reset?
1.> reset
2.> program re-load
3.> program control is already at main()
4.> run (does it execute any fprintf()s and fail after a few?)

I'm trying to establish :- if the first run after target connect and program load is just by chance, because of the way the memory is initialized when target is connected?
Also I'm trying to see if this is a stack/heap problem? using C I/O calls need bigger stack and heap sizes compared to applications that doesn't use the C I/O routines.

Please go through below wiki, it might help you with your debug as well.
processors.wiki.ti.com/.../Tips_for_using_printf



Best Regards
Santosh Athuru

Hello and thank you for answering me again. Here goes my reply:
"You mentioned that the application doesn't work, once it hits fprintf() after reset->restart->run. I'm assuming that after reset and restart, the program control reaches main() and you are able to step through the code till it reaches fprintf() and that is where you see the error."
You are right with this.
"one thing I forgot to ask or didn't see, is that the fail occurs at the first fprintf() or fail occurs after a few?"
This is kind of tricky. Now I am trying it and it always fails after the first fprintf but I remember that occasionally it failed after some executions (I could not reproduce it).
"What happens if you do a program re-load after you hit reset ? below steps:
1> reset
2> program re-load
3> reset
4> restart
5> run (does it execute any fprintf()s and fail after a few?)"
I tried this sequence:
1>click on debug icon (launch and load as far as I am concerned)
2>execute for the first time (everything is ok)
3> reset
4> program re-load
5> reset
6> restart
7> run (it failed at the first fprintf() call)
Then I tried this sequence which is the same than the latter without the execution done in the second step:
1>click on debug icon (launch and load as far as I am concerned)
2> reset
3> program re-load
4> reset
5> restart
6> run (everything is ok).
"What happens in below sequence, second time after you reset?
1.> reset
2.> program re-load
3.> program control is already at main()
4.> run (does it execute any fprintf()s and fail after a few?)"
I tried this sequence:
1>click on debug icon (launch and load as far as I am concerned)
2>execute for the first time (everything is ok)
3> reset
4> program re-load
5.> program control is already at main()
6> run (it failed at the first fprintf() call)
"I'm trying to establish :- if the first run after target connect and program load is just by chance, because of the way the memory is initialized when target is connected?"
It never failed at the first execution and it always failed at the second (most of the times at the first execution of fprintf but I remember some cases in which fprintf was called a few times before the error).
"Please go through below wiki"
I have seen it but none of what is there helped me out with this issue. I have increased heap and stack but it was exactly the same.

That is a good idea, I will see what I can find out. If I realize about something, I will write you back.
Thank you.