Unknown Characters in backchannel UART communication

[GrueneNeun]

I am using a MSP430FR5969 and work purely in CCS if that does matter. When i am using the backchannel UART to print status updates or something like this about what the controller is doing while using the Coala framework, it prints additional characters not originating from my program. These characters are not printed while using the same code without Coala being used. After powerup and resuming from a previous state it prints 0xff and 0x3f a couple of times and after a while it just prints 0xf0 every few seconds. Here it is shown what i mean:

Can you maybe guide me to where this happens and if i can safely turn it off? Are there maybe other things that gets used which are not necessarily needed for the core function like GPIOs or something like that?

[amjadmajid]

Hi @GrueneNeun

There can be multiple reasons for this. Here are a few suggestions:

1. Comment out msp_printf(target_budget); in scheduler.c and search for alike statements and remove them.
2. Does this happen when you operate Coala intermittently? If yes, try on continuous power and see if the problem persists. Debugging on intermittent power is a different story ( see https://dl.acm.org/doi/abs/10.1145/2980024.2872409). One workaround is to dump the data in memory and retrieve it later.
3. Make sure that you are not reading random memory cells and print them out. CSS memory viewer may help you with this.

Regards

[przemyslaw-pawelczak]

Dear @GrueneNeun do you need any further help from us or can we close this issue?

[GrueneNeun]

Sorry for answering that late, i ran into several issues while trying to work with COALA and forgot about this thread to be honest. For the UART issue, it was indeed the line @amjadmajid mentioned which removed the unwanted characters. But CCS did not correctly compile it when COALA was built as a library, only a full clean/rebuild would actually return the expected result.

After removing the mentioned printf statement, and trying a very simple program which just let the LEDs blink (Coala is more or less just there) - we found that the MCU would not boot after flashing. It would not even turn on an LED with the fewest lines possible (even before coala_run() was called). The really weird thing about this is, that as soon as you include stdio.h and use it somewhere in the code (it does not even have to be executed, we put a "put("a")" right after coala_run() - where it definetly should not get executed) the MCU just starts working as expected again. We tried this on two different computers with different MCUs but with the same result as mentioned.

And as of today, we found an issue with global variables which are being directly declared and initialized. The linker puts them in the same place where COALAs RAM section is and which COALA happily overwrites right after calling the first WP function. Just declaring them puts them in another section and everything works as expected. Not a very tragic one, but it is important to know...

I can provide Code examples for both cases if you want them.

[przemyslaw-pawelczak]

Hi @GrueneNeun thanks for the quick response and for reporting these two issues. Yes me and @amjadmajid look forward to code examples for both of these cases. Thank you for testing our code so extensively!

[GrueneNeun]

For the first part, i will post you two versions, the first one is the one where we encountered the problem, completely unshortened and with a complete lock of the MCU if you keep the sprintf statement commented out.
unshortened.txt
The second version will actually boot, but if you comment the "puts" statement coala wont run.
shortened.txt

Both files were run on an MSP430FR5969 under windows using only CCS with Coala compiled as a library and the .ld file @amjadmajid pointed me to in #1.

[GrueneNeun]

For the one regarding the global variables, i slightly modified the shortened example. As you can see if you run this, test is printed as 255 despite being not changed at all in the code. As i tried to debug this, i discovered that this seems to happen in __swap_page in dataprotect.c during the first call of the WP macro.
globalvar.txt

As stated above, this does not happen for just declared global vars with later initialization or if you initialize one with 0.

[GrueneNeun]

Please tell me if i can provide you with more information.

[przemyslaw-pawelczak]

Thanks for the examples @GrueneNeun I guess this is what we need for now. Me and @amjadmajid will get back to you soon

[amjadmajid]

Dear @GrueneNeun

1. I/O operations: Using the standard I/O C library on MSP430 is not advisable. These functions require a lot of resources. If you really need to use them, you need to make sure that they do not conflict with Coala (See the TI community discussion about using printf with msp430)
2. Normal global variables are not allowed in Coala as they are not protected against power failures. I you need to declare one for debugging prefix it with __nv to move it to the non-volatile memory (assuming you are using the modified linker script).
3. You can have a look at a primitive debugging suite that I developed for initial testing (it includes debugging over UART (no printf or alike functions), a power reseter, and a profiler)

[GrueneNeun]

Dear @amjadmajid,

maybe i could not make myself clear - my problem is not that printf or other functions in the stdio library conflict with Coala. My problem is, that WITHOUT using one of these functions (tried sprintf and puts) Coala will NOT work. Please see the attached code files and try for yourself what happens if you comment out the sprintf or puts lines.

I am fully aware that normal global variables are not protected against power failures and i am not using them in such a way. I am using them more like you did in the "sort" example. My point is, if you initialize them together with the declaration, they will end up in a memory section which Coala uses for RAM and so get overwritten. Again, please see the attached file in one of the previous posts and have a look for yourself.

[amjadmajid]

WITHOUT using one of these functions (tried sprintf and puts) Coala will NOT work.

Coala goes into an infinite loop. Look at scheduler.c. So, executing code after Coala_run is erratic behavior.

see the attached code files and try for yourself

I am not actively working on this or a like code, so, it is hard for me to debug.

I am using global variable more like you did in the "sort" example.

in sort example we are declaring them as const while you do not. Consequently, sort global variables are written to ROM while yours in RAM.