MSPM0L1304: Error in the "printf" output

I see the same thing. (I imported an "empty" project and inserted a printf() call.)

What the linker is trying to tell you is that it didn't find a ".sysmem" section definition in device_linker.cmd, but I can see a definition (" .sysmem :   > SRAM") right there. I fooled around with blanks and linker options, and I'm convinced the linker is reading that line.

If you're wondering: It only showed up now since something in printf() (CIO?) uses this section while nothing did before. A workaround would be to use snprintf() and write to (e.g.) the UART (which I recognize is much less convenient).

Sorry, I don't have an answer. Maybe the linker people do?

Doing the emptyproject/add printf() worked fine on the MSPM0G3507.

I could not see a "tinyprintf" option.

Keith: Did you get any Warnings from the linker? I see one for either the G3507 or the L1306.

On those MCUs, the link step succeeds since there's enough SRAM to accommodate the "invented" .sysmem section plus everything else. On the L1304, this ".sysmem" eats up all the SRAM and things go downhill after that.

[Edit: Minor clarification.]

[7]Invoking: Arm Linker
[8]"C:/ti/ccs2000/ccs/tools/compiler/ti-cgt-armllvm_4.0.1.LTS/bin/tiarmclang.exe" @"syscfg/device.opt"  -march=thumbv6m -mcpu=cortex-m0plus -mfloat-abi=soft -mlittle-endian -mthumb -O2 -gdwarf-3 -Wl,-m"empty_mspm0g3507_nortos_ticlang.map" -Wl,-i"C:/ti/mspm0_sdk_2_03_00_07/source" -Wl,-i"C:/Users/kbarkley/workspace_ccstheia/empty_mspm0g3507_nortos_ticlang/Debug/syscfg" -Wl,-i"C:/ti/ccs2000/ccs/tools/compiler/ti-cgt-armllvm_4.0.1.LTS/lib" -Wl,--diag_wrap=off -Wl,--display_error_number -Wl,--warn_sections -Wl,--xml_link_info="empty_mspm0g3507_nortos_ticlang_linkInfo.xml" -Wl,--rom_model -o "empty_mspm0g3507_nortos_ticlang.out" "./empty_mspm0g3507.o" "./syscfg/ti_msp_dl_config.o" "./startup_mspm0g350x_ticlang.o" -Wl,-l"syscfg/device_linker.cmd"  -Wl,-ldevice.cmd.genlibs -Wl,-llibc.a

[9]warning #10210-D: creating ".sysmem" section with default size of 0x800; use the -heap option to change the default size

[10]Finished building target: "empty_mspm0g3507_nortos_ticlang.out"

Just the error about the default sysmem size. Not sure why I cannot copy and paste colored text.

Another workaround presents itself in the message: If I set "Project->Properties->Tools->Linker->Basic->Heap Size" to 16, not only is .sysmem section size set to 16, I don't get the Warning either(!). Go figure.

To Christian: This is a workaround, not a fix. In my build, it looks like .sysmem only needs to be 16 bytes, but you may (or may not) need to fool with this number a little.

[Edit: But I don't get any printf [CIO] output either. I haven't used this feature for years, so maybe I'm doing it wrong.]

You may need an fflush or make sure that you don't fall through to end main. I think it takes time for the debugger to realize that there is stdio to print.

If I set the heap size to 256, I don't get CIO output, but if I set it to 512 I do get CIO output. I suppose the required size is somewhere in between. Setting the heap size is in fact the fix. The Original Poster will have to decide whether giving up 0.5KB of SRAM for printf() is worth it.

I think I see what was happening here: It seems that printf() (or maybe CIO proper) uses malloc, which uses ".sysmem", which the linker Knows is of size <heap_size> (not the size of the input section), so it creates that section with the larger size.

The Warning message looked similar enough to the linker warning about "creating section <mumble> without a SECTIONS specification" that I mis-read it. The emphasis in this message is on "with a default size", which indeed is quite large.

[Edit: Fixed muddled sentence.]

I should also mention here that I found printf (or at least snprintf) to be a stack hog as well. I've forgotten the exact number, but I found a comment I wrote (for the C1104) that says "#define USE_PRINTF 0  // 600B of stack is too much". That would be in addition to the CIO requirements.

[Edit: Added a bit of context.]