MSP430FR2675: How to enable printf output to console in CCS 10?

pcpro178 said:

Oddly, when I run the Hello World starter project in the debugger, I am able to see the "Hellow World!" output to the console.  Although it does unexpectedly break on line 114 in `__TI_writemsg()`. 

I can repeat that behaviour with a MSP430FR2633 in a CAPTIVATE-FR2633, using a CAPTIVATE-PGMR as a debugger.

In the project configured as:

• CCS 10.4.0.00006
• TI compiler v21.6.0.LTS
• --printf_support=nofloat
• --heap_size=300
• --stack_size=300

When start the debugging session and halted at the start of main() then the FRCTL0 registers shows NWAITS as one wait state:

If attempt to step over the printf() call then end up in trgmsg.c:

The way printf() works with the TI compiler is that the debugger sets a breakpoint on the C$$IO$$ symbol which is inside the __TI_writmsg function in trgmsg.c, and after the breakpoint is hit the debugger is supposed to read the printf() output from the CIO buffer, display it on the Console and then continue the target automatically.

In the above noticed that the breakpoint is reported at address 0x00E39C where as the actual address of the C$$IO$$ symbol is 0x00E3AC in the above example program.

Looking at the MSP430FR2633 Device Erratasheet (Rev. S) noticed the following:

After the program was halted at the start of main, in the Registers view manually set the FRCTL0 register to 0xA500 to set NWAITS to zero. Now, when step over printf() call get the output on the console and no spurious halt in trgmsg.c:

Since the change in behaviour occurred when just changed the NWAITS from 1 to 0, i.e. no change to the compiled program nor CCS project settings, it just suggest errara EEM23 is the cause of the problem.

I don't have a MSP430FR2675 to repeat the test with, but that device has the same EEM23 errata listed.

pcpro178 said:

This leads me to believe that something needs to be configured in the project settings.

In the past found that insufficient heap space would cause printf() to silently produce no output on the CCS console, when the malloc() call inside setvbuf() which is called when printf attempts to generate output failed to allocate space for the output buffer (BUFSIZ is set to 256 bytes).

Based on tests 300 bytes of heap should be sufficient for printf to work.

On both MSP430FR2355 and MSP430FR2675 the default linker command files place the .sysmem (used for malloc) and .cio sections in FRAM:

        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)

What I found with a printf test on a MSP430FR2355 is that when a project is created the default is that that under the CCS Project Properties "Enable FRAM Write Protection (FRWP)" is ticked:

With "Enable FRAM Write Protection (FRWP)" ticked then printf output from a MSP430FR2355 worked.

When "Enable FRAM Write Protection (FRWP)" was unticked then printf output didn't work; single stepping showed that malloc() was returning NULL even though the 300 bytes of heap set in the linker options should have been sufficient. With "Enable FRAM Write Protection (FRWP)" unticked then the SYSCFG0 register was set such all of the FRAM program memory was write-protected, with caused printf to produce no output.

Where with "Enable FRAM Write Protection (FRWP)" ticked, SYSCFG0 was set such that the lower 1Kbyte of program FRAM which contained the .cio and .sysmem sections was writable and the rest of program FRAM was write protected.

While I don't have a MSP430FR2675 to test it, I think the same applies to that device. I.e. under Project Properties check what "Enable FRAM Write Protection (FRWP)" is set to.

pcpro178 said:

also enabled the setting for Enable FRM Write Protection (FRWP), but that resulted in a bunch of linker errors.

In the project properties under CCS Build -> MSP430 Linker -> File Search Path -> Include library file or command file as input (--library, -l) can you check that frwp_init.a is in the list:

If I take a project for a MSP430FR2675 which was successfully linking with FRWP enabled, and remove the frwp_init.a file from the list then get your linker errors.

The frwp_init.a library is ccs/ccs_base/msp430/lib/FR2xx/frwp_init.a with the CCS 10.4 installation, i.e. not part of the compiler run time library.

Without frwp_init.a being specified, the linker falls-back to trying to link a different library for the __mpu_init function which is incompatible with a MSP430FR2675, as tries to access FRAM MPU registers which don't exist in a MSP430FR2675.