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.

RTOS/MSP432E401Y: ADC Sequencer not working with ADCBufMSP432E4_PK_3_A19

Part Number: MSP432E401Y

Tool/software: TI-RTOS

Dear TI-Expert,

I have a strange problem in getting adc channels 16 .. 19 working with the sequencer. I'm using a program derived from adcbufmultichannel with the following entry in the ADCBufMSP432E4_Channels structure array for channel 19:

    {
        .adcPin = ADCBufMSP432E4_PK_3_A19,
        .adcSequence = ADCBufMSP432E4_Seq_0,
        .adcInputMode = ADCBufMSP432E4_SINGLE_ENDED,
        .adcDifferentialPin = ADCBufMSP432E4_PIN_NONE,
        .adcInternalSource = ADCBufMSP432E4_INTERNAL_SOURCE_MODE_OFF,
        .refVoltage = 3300000
    },

It needs the ADC_SSEMUX0 to be one at the corresponding bit position. This channel has further no differntial pin - like no pin in my project.

I get strange readings from the ADC. When debugging after the call of ADCBuf_convert  I get the following register values:

Channels 16..19 are used by ADC1 sequencer 0, 5th ..8th sample.

As you can see the ADC_SSEMUX0 bit is not set, but the ADC_SSCTL0_D7 bit (8th Sample Differential Input Select) is set.

The same issue got observed for ADC0 sequencer 1, 4th sample for channel 19. Thus it seems not to be related to a specific ADC or sequencer or the position in the sequence. I tried another channel <16 instead of channel 19 and it worked fine.

I suspect the definitions

#define ADCBufMSP432E4_PK_0_A16 ((16 << 16) | 0x6101)
#define ADCBufMSP432E4_PK_1_A17 ((17 << 16) | 0x6102)
#define ADCBufMSP432E4_PK_2_A18 ((18 << 16) | 0x6104)
#define ADCBufMSP432E4_PK_3_A19 ((19 << 16) | 0x6108)

in ADCBufMSP432E4.h to be wrong, such that ADCSequenceStepConfigure writes into the wrong registers.

Could you check those?

  • Sven,
    I will try and recreate the issue as well as reach out to the author. I will provide some feedback by the end of the week.

    Chris
  • Sven,
    Thank you for bringing this to our attention. Do you still need a workaround or do you have a path forward?

    Chris
  • Hello Chris,

    I didn't look deeper into the issue, but still need a solution. Could you provide a workaround?

    Will the issue be solved in the next release?

  • Sven,

       I have attached a project with the work around.  Both the sequence control and the sequence extension registers are not being written to properly.  I believe that I have traced the issue down to the driver library but will need to confirm with my colleague.  

       In the attached project I have moved the associated TIDrivers into the project space and adjusted all associated includes to point to these 'new' files.  If you have difficulty importing the project, then you can simply add the associated files to your existing project.  Please confirm that you are getting the correct  values with the updated driver(s).

    Regards,

    Chris

    EDIT:

    My initial assessment was incorrect.  As you correctly noted the issue is with the definitions for the ports.

    //#define ADCBufMSP432E4_PK_3_A19 ((19 << 16) | 0x6108)
    #define ADCBufMSP432E4_PK_3_A19 (((19-16) << 16) | 0x6108 | 0x01000000)

    Additionally I believe that the macro which extracts the channel information is also incompatible.  

    //#define pinConfigChannel(config) (((config) >> 16) & 0x1F)
    #define pinConfigChannel(config) (((config) >> 16) & 0x10F)

    An updated project with these changes (i did not update the other channels greater than 15).  

    Chris

    6433.workaround.zip

  • Hello Chris,

    thank you for providing the patch. I'll check it as soon as I'll return from vacation (in about 2 weeks).

    I'll close the request now.

  • Hello Chris,

    I'm back from vacation and checked the patch - it is working. It is maybe more error prone to use the definitions in adc.h for channel definition, like:
    #define ADCBufMSP432E4_PE_6_A20 ((ADC_CTL_CH20 << 16) | 0x5C40)

**Attention** This is a public forum