Error with 'IRQn_Type' while using with MSPM0L-1306-Q1

[redbilledpanda]

I am trying to integrate only CMSIS core in our project that uses MSPM0L-1306-Q1. I have two questions:

1. What is the include sequence for including the appropriate header files? I am using the header file 'msp.h' that came along as part of the CCS installation. Taking cues from this, I defined _DeviceFamily_IDMSPM0L130X as part of the preprocessor. It was still unable to find references to __disable_irq ,__set_PRIMASK etc so I included <core_cm0plus.h> inside the device specific file explicitly. Is this the correct way to go about it?
2. After having done that, I am not getting errors of the sort: _unknown type name 'IRQn_Type';_ . Is CMSIS not supported natively outside the STM32 world? Will I have to modify these files myself?

[JonatanAntoni]

Hi @redbilledpanda,

CMSIS-Core is not made for being used directly in user projects as it only provided Arm processor core intrinsics. In order to run it requires additional silicon-vendor specific information about the device, such as the interrupt assignments in IRQn_Type.

The latter are expected to be shipped by the silicon vendor in the Device Family Pack (DFP) for your device. The core headers from CMSIS-Core are then included via the device header files provided by the DFP.

If it happens that you don't have a DFP for your device you'd need to hand-craft one yourself. You can use the generic templates in Cortex_DFP as a reference, see https://github.com/ARM-software/Cortex_DFP/blob/main/Device/ARMCM0plus/Include/ARMCM0plus.h

[KeilChris]

The CMSIS-Pack for the MSPM0L1306 should be available here: https://software-dl.ti.com/msp430/esd/MSPM0-CMSIS/MSPM0L11XX_L13XX/latest/exports/TexasInstruments.MSPM0L11XX_L13XX_DFP.1.2.1.pack

[redbilledpanda]

The CMSIS-Pack for the MSPM0L1306 should be available here: https://software-dl.ti.com/msp430/esd/MSPM0-CMSIS/MSPM0L11XX_L13XX/latest/exports/TexasInstruments.MSPM0L11XX_L13XX_DFP.1.2.1.pack

Hello @KeilChris .

Thank you for pointing me to the DFP pack for MSMP0L. So as I understand, I am supposed to generate the header file using the SVDConv utility is that right? What confuses me now is which --fields option am I supposed to use with it? I see there are four available, enum, macro, struct and struct-ansic. or am I supposed to use all of them?

Could you point me to what they mean and how are they are supposed to be used?

UPDATE: I turned on all those --fields option which created a file MSMP0L130X.h . Now this is #includeing a file named system_MSPM0L130X.h. Where am I supposed get this file from?

[KeilChris]

Hello @redbilledpanda, I did not check the contents of the pack. After your email, I checked it and I must say that it is unusable. Main files (such as device header, system, and startup files) are missing. I wonder who has tested this at TI. I will talk to TI to see if they can produce an updated version of the pack. I would also suggest to you to contact TI support to make them aware of this.

[redbilledpanda]

Thank you for the confirmation @KeilChris . The file that I generated using the SVDConv utility, turning on ALL --fields options is here. Is this the 'device file' that we're talking about here?

If I do not intend to use CMSIS for System and Clock related activities, can I comment the #include system_MSPM0L130X.h inside of this file and use it for other core related tasks (like interrupts and timers)?

[KeilChris]

Hello @redbilledpanda, I have talked to TI. They recommend to download the SDK which contains all the files you need: https://www.ti.com/tool/MSPM0-SDK#downloads.

[JonatanAntoni]

If I do not intend to use CMSIS for System and Clock related activities, can I comment the #include system_MSPM0L130X.h inside of this file and use it for other core related tasks (like interrupts and timers)?

Yes, system_MSPM0L130X.h functions are typically not used from anywhere else than startup.c. The bare minimum you need in the device header file is the interrupt enum. And in the startup.c you need the low-level entry (Reset_Handler) and the interrupt vector table.

[redbilledpanda]

Thanks a lot @JonatanAntoni and @KeilChris

Christopher, I have the SDK downloaded as part of CCS installation. As part of it, I see the startup file for MSPM0L130x for the TI ARM clang compiler which is what I want. I do not see any system file for this particular MCU though. Nonetheless, as Jonatan confirmed, it is OK if I do not need to use the functions in this file.

Another question I have is, what exactly is the "device file" that we are talking about here? I am assuming it is the file that I generated from the SVD which is here. In case it isn't, do tell me what it is and where to get it from.

Lastly, I see no scatter file anywhere. Neither in the device pack nor in the SDK. Perhaps it isn't needed in my case? In case my understanding is off the mark, please let me know.

[JonatanAntoni]

Another question I have is, what exactly is the "device file" that we are talking about here? I am assuming it is the file that I generated from the SVD which is here. In case it isn't, do tell me what it is and where to get it from.

Yes, exactly. This is the "device header file". Unfortunately, the one you generated only exposes the processor exceptions but no peripheral interrupts. This might be a shortcoming of the SVD file not containing any interrupt information.

Lastly, I see no scatter file anywhere. Neither in the device pack nor in the SDK. Perhaps it isn't needed in my case? In case my understanding is off the mark, please let me know.

Some kind of linker script is probably required for TI Compiler but I don't have any detail knowledge about this toolchain, sorry. You can find some standard linker scripts for Arm Compiler and GCC as part of the Cortex_DFP, see https://github.com/ARM-software/Cortex_DFP/tree/main/Device/ARMCM0/Config.

[redbilledpanda]

Thank you @JonatanAntoni

Regarding the "device header file", indeed the file that I generated looks to be an incomplete version of the device header file available as part of the TI SDK, which I reproduce here. Perhaps it has got to do something with the various options passed to the SVDConfig.exe tool? I used all the --fields switch with the tool but I am not sure what they mean and how it's supposed to be used. The TI version seems to be way smaller than the one I generated but it does have all exception interrupts. Plus the generated file has all manner of other unions that don't seem to be present in the TI version. Between the two, I lean towards the one the SDK supplies. It does look like TI recommends the SDK for MSMP0L130X family of MCUs and relying on CMSIS entirely (as it currently stands) won't cut it.

For the linker file, could you please tell me what dependency it has on the toolchain besides the terminology for defining memory sections? IMHO the actual content of such a script depends on the memory map of the underlying MCU. Right? What about external peripherals? they don't need to be accounted for in this script or do they?

[JonatanAntoni]

SVDConv generates device header files based on the information found in the device SVD file. If this file lacks information, e.g., about interrupts, SVDConv can't generate this bit. The flags for SVDConv just affect the way the peripheral structures are generated. I'd suggest to make use of the vendor provided header files.

The linker script depends on the linker technology. Arm Toolchain ships Arm Linker which uses Arm Scatter files (.sct). GCC and LLVM both rely on the GNU Linker and GNU Linker scripts (.ld). IAR Toolchain again is totally different.

The linker scripts must reflect the memory layout for your target device and some additional settings like entry point and startup code placement. There might be a dependency to the used C library as well.

I understand you are using the TI Toolchain so I guess the TI community would be a better point of contact.