TMS320F28379D: Cannot find ANALOG PinMux module configuration in SysConfig

Hi Rob,

What version of C2000Ware are you using? When I try the same thing I get the following error message:

This goes away when I add the ASYSCTL module in the CPU1 window, however this may only be possible on newer versions of SysConfig.

Thank you,

Luke

Hello Luke,

Thanks for the quick response.

I'm using C2000Ware 5.01.00.00. SysConfig is version 1.18.0 +3266, which I will be upgrading (though it should not affect the code generation scripts)

We also had the same ASYSCTL message, which was solved when we added this module.

The Analog PinMux error does remain, as there is no Analog PinMux module to be found in SysConfig, for this MCU, in either CPU1 or CPU2 context.

Hi Rob,

The Analog Pinmux module is part of the raw SysConfig tool. If you do not specify a Software product in the SysConfig start up screen or in your project properties you will see it.

Can you confirm this issue is specific to CPU2? If you add an ADC on CPU1, do you still see this error?

Thank you,

Luke

Ah, I did not know about this 'raw' SysConfig concept. When I create a new project without choosing a Software Product sysconfig does generate a pinmux.c/h file. This file contains a GPIO multiplexing configuration, but no mention of analog pinmux. In this mode, there is no option to add an ADC configuration (the 'Peripherals' group in the left bar does not show an 'ADC' category).

Yes, this is only on CPU2. We use ADCC on CPU1 already, without any issues.

I am more and more convinced that there is no Analog PinMux present on this MCU, and the error reported is entirely spurious;

The F28379D datasheet shows that the ADCINxy pins are either dedicate to only ADC inputs, or shared with comparator or DAC pins. The 'MUX POSITION' column is empty for all ADCIN pins. The technical reference manual ADC chapter does not mention any analog multiplexing support (other than for some control/event signals, for example ADCEXTSOC via the XBAR, and ADCSOCA0 via GPIO8 mux 3). If there is any Analog PinMux, we cannot find it.

We have traced the origin of the error to driverlib/.meta/acd.js, line 1740. This throws an error in function onValidate(), when the context is CPU2 on a multicore sysConfig. The check requires the other context (CPU1) to have the module /driverlib/analog.js present. When we disable this error, the code is generated without errors, and the generated code compiles correctly. I cannot say this produces reliable code, as we have disabled a part of the error checking...

But of course, we should not have to modify the TI code generation to get this to work.

Is there an Analog PinMux module which we cannot find, or is there a bug in SysConfig/C2000Ware?

Best regards,

Rob

A convenient way to reproduce the issue is to import project C2000Ware_5_01_00_00\driverlib\f2837xd\examples\dual\led\CCS\led_ex2_sysconfig.projectspec, then add an ADC to CPU2 (and set ADCCLK = input / 8, add ASYSCTL to CPU1)

You will see the error in sysconfig, as well as during the build step.

Hi Rob,

I was able to produce the issue on my side as well. This seems to be an error in SysConfig, and error check you removed may in fact be unnecessary. I will look into this further to determine how this should be fixed in SysConfig and guide you through the steps to implement the fix on your side. Otherwise this issue will be fixed in version 5.03 of C2000Ware.

Thank you,

Luke

All right, I will keep the error suppressed for now and continue development.

For reference, I made the following change in C2000Ware_5_01_00_00\driverlib\.meta\adc.js

Line 1740, which is in function onValidate(), was changed from

if (Common.isModuleOnOtherContext("/driverlib/analog.js") == false) {

to

if ((Common.isModuleOnOtherContext("/driverlib/analog.js") == false) && !["F2837xD"].includes(Common.getDeviceName())) {

This prevents this error from being raised for the F2837xD MCUs

Thank you Luke!

Hi Rob,

Thanks for the details on the fix you implemented. I've brought up this issue to one of our multi-core experts for SysConfig, I'll get back to you once I hear back from them.

--Luke

Rob,

Thank you for bringing this to our attention. This fix should work in the meantime. Please make sure to use the SYSCTL module on CPU1 to hand ownership to CPU2.