• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 515 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0G3507: Updating version of SDK and Sysconfig

Alan
Prodigy 155 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Returning to a project after a few months, I see that there are updates to some of the project Dependencies.  Both MSPM0 SDK and Sysconfig show that there are later versions to be had.

  • MSPM0 SDK 1.20.0.05 -> 2.0.1.00
  • SysConfig 1.18.0 -> 1.19.0

What's the right way to update my project to use the correct versions?  Simply selecting different versions and hitting "Rebuild" resulted in either compiler or linker errors depending on the different versions I chose.  The end error appeared to be in SDK code, and it doesn't seem likely that I should need to edit that to fix the problem.  Do I need to regenerate the project in some way, or are there breaking changes to the SDK that I need to update my code to support?

  • +1
    TI__Genius 15690 points

    Hi Alan,

    The process I follow to update these versions are just to download the new SDK and the new version of Sysconfig, then when I import a new project CCS automatically applies the latest version of the SDK.

    To update the version that you use in an existing project, you'll still need to download the new versions. Then select your project, right click it and navigate to properties. Then navigate to the General tab, and inside that tab, open the Products tab. Now you should see MSPM0 SDK [version} and SysConfig [version]. You can now select each one, hit edit, and the dropdown with the version number should allow you to select the newest version of the SDK. If you don't see it there, try restarting CCS.

    Please let me know if this fixes the issue, I am speaking from memory as I have been using the latest SDK for a little bit now and can't retest without a ton of extra steps.

    Also just an FYI, the SDK version we are currently on is 2.00.00.03.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    Dylan

    Thanks for the suggestions.  I had tried the steps that you suggest to update an existing project, but this is what had given me the errors when I rebuilt the project.  From what you suggest, this *should* work - however when I rebuild with the latest versions offered I get several instances of the below error:

    ti/driverlib/dl_adc12.h:523:57: error: 'ADC12_MEMCTL_VRSEL_VDDA' undeclared (first use in this function); did you mean 'ADC12_MEMCTL_VRSEL_OFS'?

    This is several functions deep into code from syscfg/ti_msp_dl_config.c.

    I rechecked my versions - I'm definitely being offered MSPM0 SDK 2.0.1.00.

  • 0 in reply to Alan
    Prodigy 155 points

    Dylan

    When I look at Github (https://github.com/TexasInstruments/mspm0-sdk/tags) I can see the latest tagged version is 2.00.00.03, and this recently contains a change to driverlib that would appear to correct the error in my previous post (https://github.com/TexasInstruments/mspm0-sdk/blame/main/source/ti/driverlib/dl_adc12.h#L523).  However the TI documentation page (https://dev.ti.com/tirex/explore/node?node=A__AEhpki4PRnEhYjiindtkLw__MSPM0-SDK__a3PaaoK__LATEST) references 2.00.01.00.  I can't quite tell how this matches what's in Github.

    I *think* that the answer to my original question about updating versions may have been as simple as you described earlier (and if that's the "official" way to do it I'll happily mark that as the solution).  However, can you confirm that you see an issue with using Sysconfig-generated code/driverlib to select the reference voltage for an ADC given the same versions as me?

  • 0 in reply to Alan
    TI__Genius 15690 points

    Hi Alan,

    Sorry for the slow response. It looks like the software team had released a version that included an issue with the ADC library, as well as the LCD example, and possibly some others. As you mentioned the ADC issue is fixed now, and my software team has mentioned that they had to go in and fix the LCD example. So yes you can consider the above response to be the "official" way to update the SDK used by your example, the actual problem area was just in the version that was released.

    I will say, after you mentioned that you can see our documentation updated to use 2.00.01.00, rather than 2.00.00.03, I went to check and download the version you use, and I did not run into the same errors. I would assume that it had just already been fixed by the time that I downloaded the SDK. I also downloaded from TI.com, whereas it sounds like you downloaded from Github. I would have to check but I assume the software team started the release, found some issues, and corrected them before releasing to TI.com. Either that or it was just fixed on TI.com between the times you and I downloaded it.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    The only option I've used for getting updated library versions is to use CCS Theia to request updates.  I assume that this is downloading from the correct location.  I've just told it to get the latest versions and Sysconfig went up to 1.20.0, but I can still only choose the same version numbers in my project and am seeing the same error with the ADC that I had previously.

    If a particular version was changed on TI.com but its number wasn't updated, how can I force a redownload of that version to get the fix?

  • 0 in reply to Alan
    TI__Genius 15690 points

    I talked to our software team and it looks like the download should still get you the same source files. Between versions 1.30 and 2.00, the ADC12_MEMCTL_VRSEL_VDDA define was renamed, so it sounds like your application used the v1.20 driverlib, but was referencing the new header files from v2.00.01.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    That sounds likely - SysConfig is regenerating ti_msp_dl_config.c, which references dl_adc12.h which is where the incorrect define is located.  So is there a way to get the updated version of driverlib - I'd assumed this might be updated alongside the SDK, but it sounds like that's not the case?

  • 0 in reply to Alan
    TI__Genius 15690 points

    Downloading the new SDK will download the updated version of driverlib. 

    I think I was misinterpreting where exactly the error is being thrown, can you please post an image of your error log for clarity? 

    If you are still getting the error:

    ti/driverlib/dl_adc12.h:523:57: error: 'ADC12_MEMCTL_VRSEL_VDDA' undeclared (first use in this function); did you mean 'ADC12_MEMCTL_VRSEL_OFS'?

    Then it just seems like your project is still referencing the older version of Driverlib from previous SDK releases. Can you verify that when you go to project properties->General->Products and confirm that the indicated version of the SDK is currently 2.00.01.00? This may seem redundant but I want to make sure we are checking off the simple explanations first. Your new SDK download should include the new version of driverlib, which would work with the header files generated by the new version of Sysconfig. 

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    I checked the dependencies in my project:

    I then right-clicked on the project in the sidebar explorer and chose "Rebuild Project(s)" - lots of compiling happened, along with some errors.  I right-clicked again and chose "Build project(s)" to get it to just attempt to build the files it failed on last time so the errors are more obvious, and the below error was produced (actually twice, in function SYSCFG_DL_ADC12_0_init() and SYSCFG_DL_ADC12_1_init() but it's the same in each case).

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    [2]Building file: "syscfg/ti_msp_dl_config.c"
    [3]Invoking: GNU Compiler
    [4]"C:/ti/gcc_arm_none_eabi_9_2_1/bin/arm-none-eabi-gcc-9.2.1.exe" -c -mcpu=cortex-m0plus -march=armv6-m -mthumb -mfloat-abi=soft -D__MSPM0G3507__ -I"D:/msp0g3507__projects/dma_output_gpio" -I"D:/msp0g3507__projects/dma_output_gpio/Debug" -I"C:/ti/mspm0_sdk_2_00_01_00/source/third_party/CMSIS/Core/Include" -I"C:/ti/mspm0_sdk_2_00_01_00/source" -I"C:/ti/gcc_arm_none_eabi_9_2_1/arm-none-eabi/include/newlib-nano" -I"C:/ti/gcc_arm_none_eabi_9_2_1/arm-none-eabi/include" -O2 -ffunction-sections -fdata-sections -g -gdwarf-3 -gstrict-dwarf -Wall -MMD -MP -MF"syscfg/ti_msp_dl_config.d_raw" -MT"syscfg/ti_msp_dl_config.o" -I"D:/msp0g3507__projects/dma_output_gpio/Debug/syscfg" -std=c99 @"syscfg/device.opt" -o"syscfg/ti_msp_dl_config.o" "syscfg/ti_msp_dl_config.c"
    [5]subdir_rules.mk:31: recipe for target 'syscfg/ti_msp_dl_config.o' failed
    [6]In file included from D:/msp0g3507__projects/dma_output_gpio/ti/driverlib/driverlib.h:36,
    [7] from syscfg/ti_msp_dl_config.h:54,
    [8] from syscfg/ti_msp_dl_config.c:41:
    [9]syscfg/ti_msp_dl_config.c: In function 'SYSCFG_DL_ADC12_0_init':
    [10]D:/msp0g3507__projects/dma_output_gpio/ti/driverlib/dl_adc12.h:523:57: error: 'ADC12_MEMCTL_VRSEL_VDDA' undeclared (first use in this function); did you mean 'ADC12_MEMCTL_VRSEL_OFS'?
    [11] 523 | #define DL_ADC12_REFERENCE_VOLTAGE_VDDA (ADC12_MEMCTL_VRSEL_VDDA)
    [12] | ^~~~~~~~~~~~~~~~~~~~~~~
    [13]syscfg/ti_msp_dl_config.c:368:32: note: in expansion of macro 'DL_ADC12_REFERENCE_VOLTAGE_VDDA'
    [14] 368 | DL_ADC12_INPUT_CHAN_2, DL_ADC12_REFERENCE_VOLTAGE_VDDA, DL_ADC12_SAMPLE_TIMER_SOURCE_SCOMP0, DL_ADC12_AVERAGING_MODE_DISABLED,
    [15] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [16]D:/msp0g3507__projects/dma_output_gpio/ti/driverlib/dl_adc12.h:523:57: note: each undeclared identifier is reported only once for each function it appears in
    [17] 523 | #define DL_ADC12_REFERENCE_VOLTAGE_VDDA (ADC12_MEMCTL_VRSEL_VDDA)
    [18] | ^~~~~~~~~~~~~~~~~~~~~~~
    [19]syscfg/ti_msp_dl_config.c:368:32: note: in expansion of macro 'DL_ADC12_REFERENCE_VOLTAGE_VDDA'
    [20] 368 | DL_ADC12_INPUT_CHAN_2, DL_ADC12_REFERENCE_VOLTAGE_VDDA, DL_ADC12_SAMPLE_TIMER_SOURCE_SCOMP0, DL_ADC12_AVERAGING_MODE_DISABLED,
    [21] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Do I need to do something else to force any further updates?

  • 0 in reply to Alan
    TI__Genius 15690 points

    Under project properties-> resource -> Linked Resources -> Path Variables, does the file path for COM_TI_MSPM0_SDK_INSTALL_DIR correctly point to your new SDK path, or does it still point to the old one? I can see that the source your project refers to is located in ]D:/msp0g3507__projects/dma_output_gpio/ti, which isn't the default SDK install path, so I am wondering if you manually updated this at some point if the Path Variables are updating correctly to use your new SDK. It may be helpful to include a screenshot of that section of the project properties as well.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    The variables you described all appeared to be set correctly.  However, while comparing mine with a freshly created project I realised that I had a local copy of the driver files in my project directory - and it appears to have been this that was being picked up instead of the updated version.  With hindsight, I recall possibly setting this up from the "example_driverlib_src" project template - not realising that this made a copy of the source that wouldn't update in the same way.  I've removed the local copy and it now appears to be happy to compile using the updated version at the install location.

  • 0 in reply to Alan
    TI__Genius 15690 points

    Ah great okay. Sure sounds like that could've been the root cause. Glad to hear you've gotten things working! I am not very familiar with the example_driverlib_src template but it makes sense that if you set up a local copy inside of a search directory, that copy could be found and used instead of the intended copy. Thanks for sharing the information on the resolution.