• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 432 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.

LP-MSPM0G3507: ADC channel value in wrong memory index

Jens Saari
Prodigy 20 points
Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: MSPM0G3507, SEGGER

Hi,

I am implementing support for reading ADCs on a MSPM0G3507 MCU (silicon version PG1).

I am using DL_ADC12_initSeqSample() and configure a total of 10 ADC values to read using DL_ADC12_configConversionMem().

ADC0 is configured to use A0_0 (MEM_IDX_0) , A0_1(MEM_IDX_1) , A0_2 (MEM_IDX2), A0_3(MEM_IDX_3) and A0_7(MEM_IDX_4).
ADC1 is configured to use A1_0 (MEM_IDX_0) , A1_1(MEM_IDX_1) , A1_2 (MEM_IDX2), A1_3(MEM_IDX_3) and A1_7(MEM_IDX_4).

For ADC0 i configure the following sequential sample:

Fullscreen
1
2
3
4
5
6
7
8
DL_ADC12_initSeqSample(ADC0,
DL_ADC12_REPEAT_MODE_ENABLED,
DL_ADC12_SAMPLING_SOURCE_AUTO,
DL_ADC12_TRIG_SRC_EVENT,
DL_ADC12_SEQ_START_ADDR_00,
DL_ADC12_SEQ_END_ADDR_04,
DL_ADC12_SAMP_CONV_RES_12_BIT,
DL_ADC12_SAMP_CONV_DATA_FORMAT_UNSIGNED);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


And then I configure 5 conversion memory using e.g for A0_0:
Fullscreen
1
2
3
4
5
6
7
8
9
DL_ADC12_configConversionMem(ADC0,
DL_ADC12_MEM_IDX_0,
DL_ADC12_INPUT_CHAN_0,
DL_ADC12_REFERENCE_VOLTAGE_VDDA,
DL_ADC12_SAMPLE_TIMER_SOURCE_SCOMP0,
DL_ADC12_AVERAGING_MODE_DISABLED,
DL_ADC12_BURN_OUT_SOURCE_DISABLED,
DL_ADC12_TRIGGER_MODE_AUTO_NEXT,
DL_ADC12_WINDOWS_COMP_MODE_DISABLED);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


When the DL_ADC12_IIDX_MEM4_RESULT_LOADED interrupt is triggered for ADC0 I read (from the main loop. Not from the interrupt) the ADC values using DL_ADC12_getMemResult().

The problem I have seen, and the reason I am writing in this forum is that sometimes the wrong ADC values are read using DL_ADC12_getMemResult().

E.g if I apply 3.3V to ADC0_3 that on the MCU, the result sometimes ends up in the result read for ADC0_0. And sometimes (after a reboot) the result ends up in ADC0_3 as it should.

What could be causing this behaviour?

/Regards, Jens

  • 0
    TI__Mastermind 28070 points

    Hi Jens,

    It sounds like FIFO mode might be on. In FIFO mode all of the available MEMRES registers (0-11) are used like an input FIFO. So in that mode each conversion in your sequence just writes to the next MEMRES register rather than being strictly assigned like you want. Your first conversion after powerup works because you are aligned to the MEMRES0 register for that first sequence, and everything falls into the correct place.

    Do you have a call to DL_ADC12_enableFIFO somewhere in your configuration code? When running the code, in the register view in CCS (hit View -> Registers while debugging), can you check the ADC0 CTL2 register? 

    Look at the FIFOEN bit field, and make sure you either have periodic refresh set, or you refresh the register view manually by pausing the debugger or using the refresh icon. 

    We want to see that the FIFOEN bit is cleared while your code is running. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 20 points

    Hi,

    Thank you for your quick reply.

    DL_ADC12_enableFIFO() is not called from anywhere in the code.

    I am not actually debugging in code composer, but rather I am using GDB from command line.

    This call returns false indicating that FIFO enable is in fact off:
    bool ret = DL_ADC12_isFIFOEnabled(ADC0);

    But at least it's supported to have gaps in the ADC channels range? I use e.g. 0, 1, 2, 3 and 7 (4 and 5 are not used).

    /Regards, Jens

  • 0 in reply to Jens Saari
    TI__Mastermind 28070 points

    Hi Jens,

    Jens Saari said:
    I am not actually debugging in code composer, but rather I am using GDB from command line.

    Understood.

    What version of the SDK and tools are you currently using to build and program the device? 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 20 points

    I am using mspm0_sdk_1_00_00_04 and I am building using the GCC toolchain.

    To program the MCU I use either a J-link (Segger) or I program the MCU using an internal flash tool that programs the MCU via I2C (communicating with the MCU bootloader).

    I believe I can reproduce this using code composer / ticlang as well.

    Would a temporary workaround be to configure all 11 MEMRES registers for both ADC0 and ADC1?

  • 0 in reply to Jens Saari
    TI__Mastermind 28070 points

    Hi Jens,

    You should use an SDK version before 1.xx for PG1 silicon. Please see this post: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1204644/faq-mspm0-sdk-important-note-for-early-mspm0-customers

    I'm not sure how exactly this would put the device ADC in FIFO mode, but a quick test with one of the earlier SDK version examples would be a good call. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 20 points

    Hi Brandon,

    I have tried building with SDK mspm0_sdk_0_58_00_00_eng and I get the same problem. So the problem still remains.

    The values of the CTL2 register for both ADC0 and ADC1 is:
    0x4000000

    This looks ok according to the documenation. It's the reset value (0x0) for all bit fields, except that ENDADD is set to 0x4. So the bit for FIFOEN is 0.

    /Best regards, Jens

  • 0 in reply to Jens Saari
    TI__Mastermind 28070 points

    Hi Jens,

    Thanks for checking that. Just to confirm your other tools you are using for building are for the early samples as well (CCS 12.1 or earlier etc.)?

    Your CTL2 register settings seem correct to me. After you enable power to the ADC using DL_ADC12_enablePower, do you wait at all before writing the peripheral registers? 

    Best Regards,
    Brandon Fisher