CCS/MSP430FR2155: CIO Function

Weston Bridgewater1

Part Number: MSP430FR2155
Other Parts Discussed in Thread: MSP-FET

Tool/software: Code Composer Studio

Hello,

I am working on a MSP430FR2155 part. I am trying to get the printf() statements to work in the CCS console. I have reviewed and tried all options in . During my testing, I changed the .cio and .sysmem locations from:

GROUP(READ_WRITE_MEMORY)
        {
            .TI.persistent : {}              /* For #pragma persistent            */
            .cio           : {}              /* C I/O Buffer                      */
            .sysmem        : {}              /* Dynamic memory allocation area    */
        } PALIGN(0x0400), RUN_START(fram_rw_start) RUN_END(fram_rx_start)

.bss        : {} > RAM                  /* Global & static vars              */
.data       : {} > RAM                  /* Global & static vars              */
    
.TI.noinit  : {} > RAM                  /* For #pragma noinit                */
.stack      : {} > RAM (HIGH)           /* Software system stack             */
.cio        : {} > RAM                  /* C I/O Buffer                      */
.sysmem     : {} > RAM                  /* Dynamic memory allocation area    */
.tinyram    : {} > TINYRAM              /* Tiny RAM                          */

This actually prints out in the console my printf() statements but it physical executes the hardware breakpoint for each printf() statement. CCS is not performing this function in the background retrieving the buffer from memory and printing it in the console view. The MSP430 debugger is breaking for each printf() statement and displaying the interrupt to the user. If I keep the .cio and .sysmem in the FRAM location, the memory contains of these sections do not change after a printf() statement. I am using the latest model of the MSP-FET debugger.

over 6 years ago

0 Weston Bridgewater1 over 6 years ago

Prodigy 145 points

I figured out I needed to add these lines:

/* FRAM Controller Wait */
SYSCFG0 = (uint16_t)0xA500;
FRAMCtl_configureWaitStateControl(FRAMCTL_ACCESS_TIME_CYCLES_3);

However, CCS is hitting the breakpoints inserted by the CIO feature but it does not handle this in the background. Anybody know how can you get CCS to retrieve the memory contents and continue executing the program for only user specified breakpoints?

0 Eason Zhou over 6 years ago in reply to Weston Bridgewater1

TI__Mastermind 39855 points

Hi,

Please look into the link(https://e2e.ti.com/support/tools/ccs/f/81/p/740743/2734981#2734981) first. It shows how to realize the printf function in CCS.

Eason

0 Weston Bridgewater1 over 6 years ago in reply to Eason Zhou

Prodigy 145 points

Hi,

I did get the printf() function to work to print to my serial console in CCS. However, CCS hits a hardware breakpoint every time there is a printf() function. As a result, I have to press resume every time CSS hits this hardware breakpoint (every printf()). I thought CCS would hit this hardware breakpoint in the background, retrieve the memory contents, print the content, and resume operation until a user created breakpoint is hit.

Any ideas why CCS is behaving this way?

-Weston

0 Eason Zhou over 6 years ago in reply to Weston Bridgewater1

TI__Mastermind 39855 points

Hi Weston,

You question is much related to CCS. I will move this thread under CCS.

Eason

0 Ki over 6 years ago in reply to Weston Bridgewater1

TI__Guru**** 472291 points

Hello Weston,

Weston Bridgewater1 said:
I thought CCS would hit this hardware breakpoint in the background, retrieve the memory contents, print the content, and resume operation until a user created breakpoint is hit.

This is indeed the expected default behavior of the debugger.

Weston Bridgewater1 said:
Any ideas why CCS is behaving this way?

I'm not sure. What exact version of CCS are you using? Can you provide a small reproducible test case (project + source/header + generated executable)?

Thanks

0 Weston Bridgewater1 over 6 years ago in reply to Ki

Prodigy 145 points

I am using:

Code Composer Studio
Version: 9.2.0.00013

OS: Linux, v.4.15.0-70-generic, x86_64 / gtk 3.18.9
Java version: 1.8.0_112

As far as the example project, I would create a new CCS project with main.c for the MSP430FR2155 latest compiler. Place a single printf() in main with #include <studio.h> in the header part. Debug the project and see if it breaks on printf() instead of just printing to console (assuming CIO is enabled in the project too). I was able to reproduce it with a single printf() for an empty project.

0 Ki over 6 years ago in reply to Weston Bridgewater1

TI__Guru**** 472291 points

Thanks. I tried to reproduce this with various MSP430 targets, but I was unable to see the issue (program never halted at the printf statement).

I didn't try with a FR2155 however since I don't have one.

Can your reproduce the error while debug server logging is enabled? Then zip the log and attach it to this thread

https://software-dl.ti.com/ccs/esd/documents/ccs_diagnostic-logs.html

Thanks

0 Ki over 6 years ago in reply to Ki

TI__Guru**** 472291 points

Ki said:
I tried to reproduce this with various MSP430 targets, but I was unable to see the issue (program never halted at the printf statement).

Hold on. I think I can reproduce it with one of my FR2xxx targets. Does the halt occur on line 114 of trgmsg.c?

0 Weston Bridgewater1 over 6 years ago in reply to Ki

Prodigy 145 points

Yes, that is exactly the line it breaks at in file trgmsg.c:114 per printf() statement or puts(). Any solutions to this?

0 Ki over 6 years ago in reply to Weston Bridgewater1

TI__Guru**** 472291 points

I have filed a bug for this ID: CCBT-2565). You can track progress of the bug via the below link:

https://sir.ext.ti.com/jira/browse/EXT_CCBT-2

Thanks

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

CCS/MSP430FR2155: CIO Function