MSPM0L1345: OPA1 inclusion - kills the compile

Part Number: MSPM0L1345
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

HELP!

trying to use OPA1 and it appears that "the-gods-of-the-libraries" are messing with me.  Any advice to help me move forward?

Once I include the OPA1 into syscfg, this is the response.

[5]Running script...
[6]Validating...
[7]Generating Code (empty_mspm0l1345.syscfg)...
[8]TypeError: Cannot read properties of undefined (reading 'peripheralPin')
[9] at printDefine (C:\ti\mspm0_sdk_2_05_01_00\source\ti\driverlib\.meta\opa\OPA.Board.h.xdt:153:125)
[10] at subTemplateFunction (C:\ti\mspm0_sdk_2_05_01_00\source\ti\driverlib\.meta\opa\OPA.Board.h.xdt:54:13)
[11] at C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\metaEnvironment\runtimeContext.ts:1102:11
[12] at templateFunc (C:\ti\mspm0_sdk_2_05_01_00\source\ti\driverlib\.meta\templates\Board.h.xdt:52:10)
[13] at func (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\codeGeneration\templateRunner.ts:29:39)
[14] at allowPathVisibility (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\pathsVisibility.ts:11:10)
[15] at runTemplate (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\codeGeneration\templateRunner.ts:29:13)
[16] at t.CodeGenerator.generate (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\codeGeneration\codeGenerator.ts:136:10)
[17] at iteratee (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\src\pinmux\services\codeGeneration\codeGenerator.ts:141:26)
[18] at Rt (C:\ti\ccs2011\ccs\utils\sysconfig_1.24.0\dist\webpack:\sysconfig\node_modules\lodash\lodash.js:653:23)
[19]gmake: *** [subdir_rules.mk:18: build-1430726529] Error 1
[20]gmake: Target 'all' not remade because of errors.
[21]**** Build Finished ****

OPA1  PROFILE - general purpose RRI, using pins 21,20,19.

I have not tried to use PIN CONFIGURATION, \

chopping disabled 

advance configuration - RRI, 6MHz

  • also note that if I simply add both OPAs to the syscfg, it will compile successfully. I will continue to try to parse this bug for TI.

  • Hi Roger,

    Thanks for providing the information. I will look into this and get back to you as soon as possible.

    Best,

    Owen

  • working with OPA0 for the moment - the compile error appears to arrive when i try to assign the inverting input to the IN0- pin.

    it compiles ok, with the output assigned to a pin(25), and the non-inverting input assigned to its I/O pin (28).

  • OPA1 - has the same behavior, when trying to assign the inverting input to the input pin, the gmake error occurs.

  • Hi Roger,

    You are correct, I have also been looking into the issue and it appears to be with the IN0- pin. In the datasheet, this analog feature is not associated with a Pin Name or PINCMx. There seems to be an issue with how SysConfig is interpreting the pin. If it's a compatibility issue, then a warning message may need to be added for clarification. I have submitted a ticket with the software team and they will look into this further. If I had to guess, this will most likely be fixed in one of the next couple of SDK releases.

    Best,

    Owen

  • Thank You  Owen, the terminology is confusing me.  Certainly the IO pins can be assigned...

    here are the pins I was planning to use on the design.

    I have them mapped out into the hardware design. Yellow highlight is what is being used. 

    Hope this helps to clarify.

  • reviewing table 6-1 I see what You are saying and this has helped to reduce my confusion.

    However, i want to be quick to add that two options for the Team.

    1) I would be OK referring to the pin connections in the syscfg as

    OPA1_IN1- (alias PNCM18 and PIN Name PA17) - physical pin 20

    OPA0_IN1- (alias PNCM25 and PIN Name PA24) - physical pin 27

    but of course the table in the datasheet would need to be updated.

    2) For the unique cases of the 134X, re-use the PINCMs and PIN NAMEs for the unique case, as shown in the screen capture

    again updating the table in the datasheet.

  • Please keep in mind that I am working against a proto and release schedule, and have my proto built. I would appreciate knowledge of possible interim workaround(s) so I can move forwward with testing the proto - helping keep schedule.

  • Hi Roger,

    The datasheet does not need to be updated, since the OPA1_IN0- pin is not connected to a pin mux. It is a fixed analog pin. The issue lies within the SysConfig software. A ticket has already been created to have this issue fixed.

    In the meantime, here is a workaround I would suggest:

    Configure the OPA as you had done previously, but in the Inverting Channel (NSEL) field, choose another option, like Open.

    Then at the beginning of Main, you can use DL_OPA_setInvertingInputChannel() to change the NSEL from Open to IN0-.

    The opa parameter can be found in the ti_msp_dl_config.h file and depends on what you named it in SysConfig:

    By default, it is OPA_0_INST.

    For the inputChannel parameter, set it to DL_OPA_NSEL_IN0_NEG.

    Best,

    Owen

  • Thank You so much.  

    I will try it out today! Then reply!.

  • Hi Roger,

    No problem. Please feel free to follow-up with any new findings or concerns.

    Best,

    Owen

  • it certainly compiled. Thanks SOOO much. Onward.

    There appears to be a problem with the pin associated with the OPA1 output - sysconfig has it as 19, datasheet shows it as 18.  

    I can close this issue out, and will create separate.

  • Hi Roger,

    Glad that the workaround worked.

    I see that in the datasheet OPA1_OUT is pin number 19:

    And in SysConfig it seems to be correct:

    Do you see something else?

    Best,

    Owen

  • indeed, revision D January 2024, Table 6-1 does show it as 19!

    However, unexplained Table 6-3 shows it as 18. Error? 

    But for me, I only need to be assured it is actually 19. which syscfg is using...

  • Hi Roger,

    Thanks for sharing. It does seem like there might be a typo in Table 6-1. I reached out to the team that works on this document to hopefully have it fixed as soon as possible.

    As for the OPA1_OUT pin, it should be pin 19.

    Best,

    Owen

  • thanks, my preference is to use Table 6-3, so thank those on the Teams for that bit of publishing.

    will update schematics, and proto accordingly... Best,