TI MSPM0: toolchain and programming

[microwhat]

Based on some research, it looks like it should be possible to program a MSPM0 (MSPM0C1103 for instance) with gcc, and flash it with a raspberry pi pico running debugprobe, but when I try to find details on actually doing the aforementioned things, it is not so clear.

I've programmed a MSP430G2553 with code composer studio 5, which hid all the ugly details, having a (magic) "compile my code and write it to the device" button.
I've programmed the RP2040 with gcc and the published sdk. Flashing that through USB was like dropping a rock and hitting the ground, but I had to trial-and-error my way through getting a CMakeLists that would compile what I wanted (particularly when I used tinyUSB).

Looking back at those projects, I realize I have no idea how I would set up such projects from scratch. CCSv5 hid most of the details, and even though I have slapped some things together with the RP2040 SDK, I don't actually understand what I did. I want to try the MSPM0C1103, but the family seems to have been built with the assumption that you will use SysConfig and CCS Theia.

I have windows 7 and a headless linux server to compile with, so I can't use Sysconfig (it won't run), and do I really need a 6GB software package to make this chip flash some LEDs?

[Renate]

Well, it's just a Cortex M0+ with SWD, so it's not rocket science.
(I don't have any experience with this TI device.)

Me? I'm stone age, so I'd use (I do use) make, gcc, (ld), objcopy and my own CMSIS-DAP programmer software with an AtmelICE programmer.
(Of course you could use OpenOCD instead.)
Compile/erase/program/run time is under two seconds

Unless you're going for the small pin count you could use a SAMD21G like in Seeed Studios' Xiao series.

[microwhat]

I've only programmed one specific ARM microcontroller that everyone and their dog has used for all kinds of things and documented from here to the horizon and back. (Except I don't understand what I've done, so I don't know what transfers to other ARM devices)

If I want to program this other ARM microcontroller, it looks like rocket science to me because I've never done that before.

[Renate]

Well, break up your problem into build vs. program.
I don't like these big GUI tools so I try not to use "Studios".

Programming can be done by OpenOCD, you should look at that.
But it drives me batty with all this "port 4444 is open for telnet" silliness.
You can run it using only .cfg files but it doesn't give proper feedback when you run it without gdb or telnet.

This is one config file:

Code: [Select]

# OCD config for STM32F411

gdb port disabled
telnet port disabled
tcl port disabled

adapter driver cmsis-dap
cmsis-dap vid_pid 0x03eb 0x2141
transport select swd
reset_config srst_only

source [find target/stm32f4x.cfg]

init
targets
reset halt

flash write_image erase blinky.hex
flash verify_image blinky.hex
reset
shutdownHa! So you made me learn something.
It takes three commands but you can turn off the stupid ports.

The stupid printout tells you lots of nonsense, but not that it's actually erasing/programming/verifying.
It will give you a message on failed verify though.

[az1]

Should flash fine with probe-rs, which is a bit more friendly than OpenOCD or pyOCD.

https://probe.rs/targets/?q=mspm0&p=0

It should be actively supported by Embassy if you wanted to sidestep the vendor nonsense (but you will easily chew through 6 GB in build artifacts).

https://github.com/embassy-rs/embassy/blob/main/examples/mspm0c1104/src/bin/blinky.rs

https://docs.embassy.dev/embassy-mspm0/git/mspm0c1103dyy/index.html

[Peabody]

There was a TI command line tool called MSP430Flasher.exe that could be used with the MSP430 parts, which could be used instead of CCS.  And it was somewhat smaller.  :-)  I wonder if there's anything similar for the M0 stuff.

[fchk]

OpenOCD does exactly this.

[microwhat]

Y'all have made it clear that openOCD etc will move a compiled program from my computer into the microcontroller. I expect I can figure the details of that step later, once I have a compiled binary in one hand and a target board in the other.

I suppose my question should have been "I have gcc-arm-none-eabi installed on a headless linux beige box and want to build a program for a MSPM0-family microcontroller. How do I find the information on which files to create and what to put in them? I can't use CCS or SysConfig because windows 7."

[voltsandjolts]

Well, as some kinda guide to show a working minimalistic layout, here's a nice example for an STM32 CM0.
https://github.com/ataradov/mcu-starter-projects/tree/master/stm32g031

Maybe download gcc and build that, then try reproducing for TI CM0. Or just use STM32, hehe.
It's my impression that TI CM0 don't get much attention around here. Or MSP430 for that matter.

[microwhat]

If that's a minimalist example, I give up. I see three files full of magic, and three folders full of other magic. I don't see any similarities between what's in your link and whatever I can find in the MSPM0 SDK, and I haven't the least idea of how to reproduce it for some other microcontroller.

Why would I need to build gcc from source when I can install gcc and gcc-arm-none-eabi from the devuan repository?

[dietert1]

IAR EWARM certainly comes with support for the TI parts and is a fantastic tool. It runs under windows. TI used to offer restricted IAR licences for MSP430, but i think that stopped when they had their own IDE. Some people like EWARM so much that they made an activation tool.

Regards, Dieter

[az1]

If that's a minimalist example, I give up. I see three files full of magic, and three folders full of other magic. I don't see any similarities between what's in your link and whatever I can find in the MSPM0 SDK, and I haven't the least idea of how to reproduce it for some other microcontroller.

Well if you don't understand Alex's example maybe it would be best to start with a C program for Linux and figure your way around make and such.  He's just included a rather simple linker script, make file, and some C source files.

Why would I need to build gcc from source when I can install gcc and gcc-arm-none-eabi from the devuan repository?

You shouldn't need to unless TI did something weird with their Arm implementation.

[Renate]

If you're going for minimal, just do like I did this week starting up with the STM32F411.

You're going to need a vector table.
For some reason, STM likes doing that in assembler.
I've got nothing against assembler and I do write stuff in it.
But in a C world, why not just write it in C?
So you can use what ever you find in .s or reformat it in C.

You're going to need a loader file, .ld
There are ones out there but you may want to customize it.

Setting up clocks? You can hold off for now.
Any device comes up running something on internal clocks and that's good enough for now.

Your program? You need a blinky.
Normally you need to route clock to a GPIO, enable it as output.
Then you just make a delay volatile int i; for(i=0;i<65536;i++) GPIOWHATEVER^=SOMEBIT;

Compile and link with your ld file and you have an ELF file
Now you need to turn that into a hex file with something like objcopy.exe -O ihex blinky.elf blinky.hex
Then flash your hex file. Does it blink?

To get real you have to set up your clock chains.
But you already have a working blinky so it's easy to tell if your setup is working when it blinks faster.

[voltsandjolts]

Maybe download gcc and build that, then try reproducing for TI CM0.

Why would I need to build gcc from source when I can install gcc and gcc-arm-none-eabi from the devuan repository?

Sorry, my bad grammar. I meant build that github example I linked.
No, don't build gcc yourself!

Try reading this intro to bare metal;
https://github.com/cpq/bare-metal-programming-guide

[Dan N]

If that's a minimalist example, I give up. I see three files full of magic, and three folders full of other magic. I don't see any similarities between what's in your link and whatever I can find in the MSPM0 SDK, and I haven't the least idea of how to reproduce it for some other microcontroller.

Most of the "magic" files are just copies of CMSIS headers from the STM32 repository.  You would replace those with CMSIS headers from the MSPM0 SDK download.  The stm32g031 and MSPM0 are both Cortex M0+ so many of these files will be identical.

You also have to modify the linker map file (stm32*.ld), and modify initialization and vector table in startup_stm32*.c to exactly match your part.

[az1]

Compile and link with your ld file and you have an ELF file
Now you need to turn that into a hex file with something like objcopy.exe -O ihex blinky.elf blinky.hex

FWIW one of the reasons I prefer probe-rs to OpenOCD or pyOCD is that it'll work with ELF (or Intel hex) files directly and apply the correct flash algorithm for each region.  No need for the intermediate step.

[westfw]

Most of the "magic" files are just copies of CMSIS headers ... You would replace those with CMSIS headers from the MSPM0 SDK download.

This.  The difference between having just gcc-arm-none-eabi, and having a build environment for a particular processor family consist of the #include files (CMSIS specifies their approximate internal structure, so they're sometimes refered to as "the CMSIS Headers"), and maybe some linker scripts (although the cortex families have pretty fixed memory layouts, so generic linker scripts will probably work.)
There may also be startup code and pre-compiled copies of an appropriately compiler newlib.  But again, those can/should be pretty generic.

Unfortunately, the directory layouts for the #include files seem to be very vendor-specific, so you may also need to craft or find some makefile template or equivalent that sets up the proper "-I xxx" switches for the compiler and similar.  Or you can re-arrange the files, I guess (which can make your source incompatible with the "pro" toolchains.)

Whether there is a convenient way to download those pieces is a separate question.  The TI "MSPM0 SDK" is a 220M download (requiring an account and login) that is apparently an "installer" that ends up putting about 1.5G on disk.  Most of that seems to be documentation.  The #includes and linker files (for just the hardware) seem to be about 7.5M

Code: [Select]

Mac-Pro<5824> du -sh mspm0_sdk_2_05_00_05/*
1.0G    mspm0_sdk_2_05_00_05/docs
292M    mspm0_sdk_2_05_00_05/examples
4.0K    mspm0_sdk_2_05_00_05/imports.mak
5.4M    mspm0_sdk_2_05_00_05/kernel
 68K    mspm0_sdk_2_05_00_05/known_issues_FAQ.html
 36K    mspm0_sdk_2_05_00_05/license_mspm0_sdk_2_05_00_05.txt
348K    mspm0_sdk_2_05_00_05/manifest_mspm0_sdk_2_05_00_05.html
 10M    mspm0_sdk_2_05_00_05/mspm0sdk_2_05_00_05.log
144K    mspm0_sdk_2_05_00_05/release_notes_mspm0_sdk_2_05_00_05.html
152M    mspm0_sdk_2_05_00_05/source
 22M    mspm0_sdk_2_05_00_05/tools
8.0M    mspm0_sdk_2_05_00_05/uninstall.app


Code: [Select]

Mac-Pro<5826> du -h mspm0_sdk_2_05_00_05/source/ti/devices/*
 12K    mspm0_sdk_2_05_00_05/source/ti/devices/DeviceFamily.h
192K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/startup_system_files/iar
184K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/startup_system_files/ticlang
192K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/startup_system_files/gcc
192K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/startup_system_files/keil
768K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/startup_system_files
336K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/linker_files/iar
160K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/linker_files/ticlang
320K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/linker_files/gcc
160K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/linker_files/keil
984K    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p/linker_files
2.6M    mspm0_sdk_2_05_00_05/source/ti/devices/msp/m0p
1.0M    mspm0_sdk_2_05_00_05/source/ti/devices/msp/peripherals/m0p/sysctl
1.1M    mspm0_sdk_2_05_00_05/source/ti/devices/msp/peripherals/m0p
5.0M    mspm0_sdk_2_05_00_05/source/ti/devices/msp/peripherals
7.6M    mspm0_sdk_2_05_00_05/source/ti/devices/msp
It probably would violate the terms of the TI license for someone to package up JUST those files.  :-(

[microwhat]

I found those files in the SDK, and have been able to compile a very short program. The /source/third-party/CMSIS is needed too.

However, I don't know how to get make to link it. Doing

Code: [Select]

arm-none-eabi-ld -T ./ti/devices/msp/m0p/linker_files/gcc/mspm0c1103.lds -nostartfile -o main.elf main.o --print-memory-usage produces a 23KB ELF, and

Code: [Select]

arm-none-eabi-objcopy -0binary main.elf main.bin produces a 1KB bin, but I don't know how to put that in a makefile.

Existing makefile and main.c attached.

[Renate]

Individual tastes differ. I like keeping to a small number of useful recipes.
I prefer not to have intermediate results as independent goals.

Code: [Select]

.PHONY: all
all: blinky.hex burn

blinky.hex: $(SOURCES)
$(GCC) $^ -o blinky.elf
$(HEX) blinky.elf blinky.hex

.PHONY: burn
burn: blinky.hex
atmelice $(DEVICE) /e /p /v /b250k $<My commands are not that similar to yours and I'm using some automatic variables.
The GCC does the ld too and has the ld file specified.
".PHONY" is being a bit pedantic, but it could help if there were confusion with an actual file.

For a full test, I just need "make".

"all" could technically just be "burn" since the dependency is there, but it seems clearer this way.

Yes, you could use some flashing tool that takes an ELF, but ELFs have lots of sections and I'd prefer to have it boiled down to where I can see it in a hex.

[az1]

Individual tastes differ. I like keeping to a small number of useful recipes.
I prefer not to have intermediate results as independent goals.

That glosses over quite a bit.  More magic if you will.  One of the upsides of GNU tools vs their proprietary predecessors is that the documentation is generally pretty good.  This will explain what the magic variables and targets do.  If OP is really stuck with how to use a compiled binary in a makefile this is a good place to start.

https://www.gnu.org/software/make/manual/html_node/index.html

Yes, you could use some flashing tool that takes an ELF, but ELFs have lots of sections and I'd prefer to have it boiled down to where I can see it in a hex.

Most of the time that's just an unnecessary intermediate step.  If there's something specific I need focus on I'll typically use objdump to figure out where something gets placed or what a section's contents are.  Debuggers typically speak ELF so if I need to run the firmware through a debugger, I'm still using the ELF product.

For me the main benefit was more approachable configuration and invocation (no more screwing around with TCL).

[westfw]

For simple setups, arm-none-eabi-gcc will run link as well compile.
Just put the linker commands on the compile  line, preceded by "-Wl,":
And add the objcopy as an additional command:

Code: [Select]

CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld
OBJCOPY = arm-none-eabi-objcopy

INCLUDES = -I./
INCLUDES += -Iti/devices/msp/m0p/startup_system_files/gcc
INCLUDES += -Iti/devices/msp/m0p/
INCLUDES += -Iti/devices/msp/peripherals/
INCLUDES += -Tti/devices/msp/peripherals/m0p/sysctl/
INCLUDES += -Iti/CMSIS/Core/Include

CFLAGS = -c -mcpu=cortex-m0 -mthumb -O0 -g
LDFLAGS = -Wl,-T./ti/devices/msp/m0p/linker_files/gcc/mspm0c1103.lds -Wl,-nostartfile

all: main.elf

main.elf: main.c
$(CC) $(CFLAGS) $(INCLUDES) $(LDFLAGS) main.c -o $@
$(OBJCOPY) -Obinary $@ main.bin

That's not really a "proper" makefile (you should have separate rules for making any .elf from .c, and any .bin or .hex from any .elf, and more), but a tutorial on how to create a Makefile is essentially beyond the scope of this discussion.
(Makefiles can be essentially arbitrarily complex, and for any given project, tend to grow in complexity until they're incomprehensible)

BTW, you probably don't want "-nostartfile", since that will leave out the vectors that an ARM needs at 0x0.

I did find an online class that covers a bunch of the "build environment" issues that are frequenly "provided withut explanation" in university classes (including Makefile stuff.)   https://www.coursera.org/learn/introduction-embedded-systems  (I apparently haven't looked at it since 2018, so I don't know if it's gotten "stale."  OTOH, "Make" hasn't changed.)

[microwhat]

I've kind-of made a c file "compile." Actually I only know that I don't see any errors when I run the script. I don't know how to assemble a makefile, or what final format I need to push to the microcontroller.

I realized I have no idea how to initialize this microcontroller, or any of its peripherals, and while the family reference guide lists all the registers one might need to know about, it doesn't say how to use or set up any peripheral.

I realized I know literally nothing useful about this microcontroller family. I know that code generators produce excessively verbose output, but I need to start somewhere. Using TI zerocode I connected two function blocks within an infinite loop, to flash one LED, and nothing else. It produced a steaming pile of gibberish, some of which I'm attaching. I was expecting about three lines of code to set up the GPIO port, and a while loop containing a time-wasting loop and a P1OUT ^= 0x01 or similar. Instead, main() has 30 lines of code that reference a bunch of other functions to do t h i n g s that seem entirely superfluous to initializing an IO pin and setting its value. I followed a few levels of includes, and I still can't tell what SYSCFG_DL_init() actually does.

When I first programmed a MSP430, it took about ten lines of code to set up GPIO, a hardware timer, interrupts and make something begin to happen. The rest was application logic. It seems if I want to use any modern microcontroller, I will have to accept the layers of abstraction, since the device is incomprehensible without it. The little I've done with the RP2040 is with the official SDK, so I don't know how to initialize that from scratch either.

Have I missed something or this just how microcontrollers are today?

(I also see that I've spent several days beating my head on the desk over the "new" $0.50 device, to save using the $2 device)

[az1]

Have I missed something or this just how microcontrollers are today?

Yeah, the documentation.  You're trying to do a lot while understanding a little.  Read the RM for your microcontroller, read the docs for GNU make, binutils, LLVM or GCC suite, etc.

I've been working with documentation that I suspect most folks would consider inferior to that for the MSPM0 and still all the information is contained within.  To get something blinking "bare metal" shouldn't take a lot.  You may have to enable a clock for GPIO stuff but that's about it.  From there you should be able to get by with a vector table that only has one entry (your reset handler / entry point).  So a few lines of whatever language and a few directives in a linker script to make sure things get placed in the proper place.

If you're stumbling over the makefile and linker scripts though you really need to go back and figure some way of learning how they work.  Cargo culting a few lines to bang the "bare metal" drum isn't much of an accomplishment and won't help you much if you're still stumbling on the fundamentals.  Start with the reference manual instead of the SDK.  There should at least be some flow charts to show you how initialization is expected to work, follow that instead of whatever the SDK is doing.

That said the RP is a bad place to start for this.  The RP is a dual core ARM (and later dual ARM + dual RISC-V) with a *lot* more moving parts to consider.

The manual is here:

https://www.ti.com/product/MSPM0C1103

Worth noting that the MSPM0 manages to make interrupts more complex than the simpler STM32s, but for getting an LED blinking without a timer that shouldn't be an issue.

[westfw]

Have I missed something or this just how microcontrollers are today?

Well, yes; both.

Yes, most 32bit microcontrollers are significantly more complex than 8 or 16bit microcontrollers.
In particular, they tend to come up with most of the chip, including clocking, disabled, so you have to start out by configuring clocks, routing the clocks to the buses that your peripherals are on, and the actual peripherals you want to use.

The other thing you missed is that putting together a development environment and programming a chip "from scratch" is essentially a different "skill set" than using a packaged IDE, and you'll need to commit some time to learning the necessary skills.  Which can be a real PITA, partly because it's "more general" knowlege, and vendors would rather lock you in to their tools so you keep using their chips.
On the plus side, it IS "more general" knowlege, so once you've learned it, it's also more portable to other architectures.

I still can't tell what SYSCFG_DL_init() actually does.

It uses TI's "Driver Library" (DL) to initialize the parts of the chip that you've configured with SysConfig.  If you're using the driverlib and sysconfig and etc, I don't think you're supposed to know more than that.  But it breaks down to:

Code: [Select]

SYSCONFIG_WEAK void SYSCFG_DL_init(void) {
//  SYSCFG_DL_initPower();
       // reset GPIO to known state.  SDKs tends to be much fussier
       //  about resetting peripherals than "amateur" code that
       //  assumes "post-reset" status.
       DL_GPIO_reset(GPIOA);
       // Enable the power domains associated with GPIOA
       DL_GPIO_enablePower(GPIOA);
       // don't know; wait for the power just enabled to stabilize?
       delay_cycles(POWER_STARTUP_DELAY);

//  SYSCFG_DL_GPIO_init();
       // Route GPIO to the appropriate pins.  Many 32bit CPUs have a
       //  mux to connect different peripherals to pins that have mutiple
       //  functions, and they don't always default to ... anything.
       DL_GPIO_initDigitalOutput(led_config_0_IOMUX);
       // Set GPIO bit to known state.
       DL_GPIO_clearPins(led_config_0_PORT, led_config_0_PIN);
       // Enable output
       DL_GPIO_enableOutput(led_config_0_PORT, led_config_0_PIN);
}


(I also see that I've spent several days beating my head on the desk over the "new" $0.50 device, to save using the $2 device)

Well; yes.  So it goes.  SOMEONE has to do it!
Worth it?   Maybe.
You have learned some things.  That's usually worthwhile...

[microwhat]

I'm revisiting this project. I've assembled a board with the MSPM0C1103, and have successfully programmed it to do things.

I am using only the Texas Instruments SDK, the MSPM0 technical reference manual, the device datasheet, gcc, and a text editor. I am not using DriverLib, SysConfig, or any purpose-built IDE.

I have read the gnu makefile documentation, and while I see the syntax described therein, I'm still not sure how to begin with a source file and the SDK and get $whateverFormatProbeRSwants. Thus, I asked a generator bot to give me a makefile which I will hand-wave for now, long enough to get something running, at which time I will make a napkin sketch of what this makefile does, write my own from scratch, and see if it gives me the correct output.

I have learned a few things:

• It is not practical to flash this family of microcontrollers on windows 7. Neither OpenOCD nor Probe-rs will run on windows 7.
• OpenOCD apparently does not support this family. I could only find device configs for MSPM0L and MSPM0G devices, but not MSPM0C.
• Probe-rs will write a *.ELF to this device, using a raspberry pi pico flashed with debugprobe
• Some register writes don't appear to take effect unless some delay is added beforehand. So far, I have added magic delays before writing to TIMG8->CLKDIV, TIMG8->CLKSEL, and TIMG14->CLKSEL. It works but I don't know why.
• I can't get SysTick to work. I've configured the registers as specified in the technical reference manual, which matches ARM documentation, and the interrupt handler never appears to run.

I'm attaching the makefile and main.c, from which I have stripped my application logic, leaving device setup and interrupt handlers.