LP-MSPM0G3507: ADC channel value in wrong memory index

Jens Saari

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:

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);

And then I configure 5 conversion memory using e.g for A0_0:

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);

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

over 2 years ago

0 Brandon Fisher94 over 2 years ago

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 Jens Saari over 2 years ago 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 Brandon Fisher94 over 2 years ago 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 Jens Saari over 2 years ago 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 Brandon Fisher94 over 2 years ago 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 Jens Saari over 2 years ago 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 Brandon Fisher94 over 2 years ago 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

Arm-based microcontrollers

Arm-based microcontrollers forum

LP-MSPM0G3507: ADC channel value in wrong memory index