MSP-EXP432E401Y: MSP432E401 ADC fails for channel numbers higher than 15.

So it seems that you change the head file, but the software doesn't configure it like what you want.

Do you use adcsignlechannel.syscfg to do the change?

You can find ADCSequenceStepConfigure() code under this link:

Yes i am using the syscfg file to do the changes. I have tested several alternative channels on the Launchpad. Everything works fine until I reach channel 15. The register setting of ADC_SSMUX and ADC_SSEMUX is correctly set for all channels lower than 15.

I have stepped through the code and it seems that the ADCMSP432E4.c feeds the adc.c with the channel number 16: (0x10) + ADC_CTL_IE + ADC_CTL_END which gives the value 0x10 | 0x40 | 0x20 = 0x70 a 7-bit number (the ui32Config parameter).

However when setting the MUX channel extension register, the lower 8 bits of ui32Config are cleared before used (ui32Config & 0xf00) leaving the value of zero for any channel selected.

HWREG(ui32Base + ADC_SSEMUX) = ((HWREG(ui32Base + ADC_SSEMUX) &
~(0x0000000f << ui32Step)) |
(((ui32Config & 0xf00) >> 8) << ui32Step));

However, if the code is written for the values defined in the adc.h file, it would have worked :

#define ADC_CTL_CH15 0x0000000F // Input channel 15
#define ADC_CTL_CH16 0x00000100 // Input channel 16

Please see attached documentation. If I'm not wrong, this code will not work.

Is this code really verified by TI?

Best regards
Terje

MSP432-adc_setting.pdf

Thank you for your detailed explanation. I need some time to dig into this issue to see if it is really a driverlib bug.

Please wait for some time.

Hello,

Have you reached a conclusion regarding my question?

Best regards

Terje

I am sorry, I don't have time to recreate the issue. I am on business travel, and will be back on next week. I assume I will come out an conclusion at the end of next week.

Sorry, I am get a little lost in your explanation.

As you said, the problem seems lies on ui32Config & 0xf00, that will always will give a value of 0x0 for the ADCSSEMUX register. But if the pin is lower than 16, this problem will still happens.

What make me confused is that, as ADC_CTL_CH15 = 0x0000000F, why ADC_CTL_CH16 not equals to 0x00000010?

The ADC channel configuration in ADCMSP432E4_PK_0_A16 is differ from the one in ADC_CTL_CH16.

Hi, yes I am sharing  your confusion, but this is code generated by the CCS when using the syscfg and "out of my hands".

However, a similar problem was already pin-pointed in 2019 and I assumed that the problem was long gone by 2021.
Please ref:

https://e2e.ti.com/support/microcontrollers/msp430/f/msp-low-power-microcontroller-forum/768140/msp432e401y-adc-channels-above-15-don-t-seem-to-work

Setting of the ADC channel-mux require accessing two 32-bit registers, the ADCSSMUX0 (offset=0x40) and ADCSSEMUX0 (offset=0x58).
The ADCSSMUX0 selects the channels [0:15] if the ADCSSEMUX0 is zero.
The ADCSSMUX0 selects the channels [16:23] if the ADCSSEMUX0 is non-zero.
(Ref. SLAU723A page 746 and 756).

The "ui32Config & 0xf00" is meant for extracting the value to be set in the ADCSSEMUX0.

This would have worked if based on the values defined in <ti/devices/msp432e4/driverlib/adc.h> line 84-107.
However, these values are not used as the .adcPin is instead defined by the <ti/drivers/adc/ADCMSP432E4.h> (line 76-109)

This alternative definition packs in more information into the .adcPin value (channel, port, pin) and when the bits are unpacked to set
the registers, this unpacking fails. This becomes clear when stepping through the code.
The parameters (ui32Step and ui32Config) given to ADCSequenceStepConfigure() is incompatible with the code of the adc.c.

Feeding the .adcPin = 0x00106101 to the PinConfigChannel () gives the number 0x10; the channel number =16d in the LSByte.

However, this is not what the ADCSequenceStepConfigure() expects. It expects 0x100 with the  most significant bit placed in
bit 8 as defined in adc.h. The reason this, i guess, is that it makes it easier to split the channel number for the two hardware registers.

Confusing? Yes!
But this is TI realm and I have no intention to re-design the TI libraries. I have designed an MSP432 board for a customer and have
promised to solve this problem somehow. If I don't get a solution from TI, I fear I have to make a copy of the libraries to make a working code.
However, this is not a tempting solution as this product is meant to stay in the market for years.

OK, I will relay the answer to my customer and discuss further steps to cure the problem until TI comes up with a permanent solution.

What puzzles me though, is that if my observation is correct, the problem has been known for two years and not fixed by TI.

I think yes. But the report of the problem is newly created by my software team. As there is some change in TI inside, I am not sure why this problem is not fixed. as there is MSP432E SDK new version come out in these years. 

OK, tanks for your support. I have oriented my customer and we will find a temporary solution so that
the product can be tested and verified.

Then I hope TI will come up with a fix within reasonable short time.