LPC55S69 Configtool ADC

[gertvb]

Good Day!

I am using an OKDO E1 board with the LPC55S69 MCU, Hardware 1B, developing with MCUXpresso 11.2.0 with SDK version 2.8.2(376 2020-08-19)

I have set up 6x ADC inputs from within MCUXpresso with the embedded Pheriperals tool of the CONFIGTOOL, instead of coding every ADC register in my own software.

Anyhow my project compiles and runs on MCUXpresso. (see attached  zip file)

BUT all the results that I read back from the ADC FIFO have the value 32768, even though my signal generator is correctly outputting the 6 sine waves into the ADC pins.

However if I FIRST run the lpcxpresso55s69_lpadc_polling example project, and then run my project, my project reads the correct values on the ADC inputs.

Telling me that I am missing SOMETHING CRUCIAL in the initialization of the ADC in my code, which is done in the lpcxpresso55s69_lpadc_polling example project.

Can someone please just check what it is that I am missing?

Kind regards

Gert van Biljon

Notes :

1. The OKDO E1 does not have a 32MHz crystal populated on the board, hence me using PLL1 from the 12MHz Free running Oscillator to generate the 150MHz I use for the core

2. I prefer the route of using the embedded Pheriperals Configuration tool from withint MCUXpresso, as until recently I was jumping between the AtSAMD51 and XMC4500 and for that I successfully used Infineon's DAVE and Atmel's Atmel Studio 7, where I didn't have to go down to register level to configure the ADC to run with DMA

3. This project was generated from scratch, but I think it should run on an lpcxpresso55s69 dev board?

[ianbenton]

I am getting results from an LPC5502 that looks as though the A/D is not powered, but I don't see a bit in the PDRUNCFG register that controls it.

In the calibration procedure the GCC registers all read zero, and all results read from the FIFO are 0x8000.

[dandy1]

Thanks to you all for a great solution. I printed off the configuration code created by the tools in MCUXpresso 11.3 and compared it line-by-line with the example given in the project LPADC_Polling. I agree that the missing line is

POWER_DisablePD(kPDRUNCFG_PD_LDOGPADC); as gertvb suggests.

If I add it as he suggests to Main() then my ADC conversion works reliably.

I used the Peripherals tool to create and set up two Timers as well as the ADC. The ADC menu has options for power and doze mode but it does not create the missing line above. The Clocks peripheral tooldoes create a similar instruction in Board_BootClockPLL150M(): >

POWER_DisablePD(kPDRUNCFG_PD_FRO192M);

The Peripherals tool exists to configure the peripherals. Perhaps the next revision of the ADC Peripherals tool should automatically create the missing power-up instruction for the ADC.

[gertvb · Accepted solution]

In this case it rather seems to be a pebkac error on my side and nothing wrong with configtools

I have not enabled the power to the ADC!

Added the following before the while (1) loop, and it now works

POWER_DisablePD(kPDRUNCFG_PD_LDOGPADC);

[gusarambula]

Hello Gertvb,

Thank you for sharing your finding! I’m glad that you could find this omission!

Regards,
Gustavo

[mark2]

Hey Gert,

I downloaded the MCUX project and ran it on my OKdo E1 board. It works just fine... once the ADC has been calibrated...

The clue was in your comment about it all working if you'd previously loaded the SDK's lpadc polling example. I've seen that from time to time.

Anyway, good luck and let us know how you get on.

Mark

embeddedpro

[mark2]

Actually, scratch that. Just tried after power cycling the board and it's back to the original behaviour. This time all 6 channels read 32768 again. But I'm sure that we're only something with the ADC.

Let me continue some tests.

[gusarambula]

Hello Gert van Biljon,

It is an odd situation that running the lpcxpresso55s69_lpadc_polling example first fixes this issue.

I haven’t checked the code in-depth, but I did notice that you are using the lpadc driver but its header is not added to the program itself. It is not necessary, but you are then not using methods from the driver in main.

This led me to notice that one of the things that the example handles a bit differently is the initialization. You will notice that all initialization is made on main. Your code is more organized, having the initialization along the peripherals. However, the driver has a method that pulls a “Default” structure for the ADC configuration and then initializes it. This allows to then initialize focusing on the desired values we want (making less likely to omit some configuration).

It wouldn’t hurt to try adding the fls_lpadc.h header on your program and then loading this default configuration to the configuration structure and then initialize on main with the changes required.

The function is:

 LPADC_GetDefaultConfig(&mLpadcDefaultConfigStruct);

I will continue looking at the code and try to test it, but I wanted to share this as from the behavior maybe it will help.

I will let you know if I find something else.

Regards,
Gustavo

[gertvb]

Hallo Gustavo!

Thanks for the reply - appreciate!

Just some observations :

>>Your code is more organized, having the initialization along the peripherals.

The only code that is mine is inside while(1) in main.  The rest of the code is actually not mine at all, but it is the code automatically generated by MCUXpresso Config Tools.

Please see the attached pdf documenting the process I followed to generate the project

>>but I did notice that you are using the lpadc driver but its header is not added to the program itself.

The auto generated file lpc55s69_configtool_adc.c which contains main(), contains #include "peripherals.h" and peripherals.h in turn contains #include "fsl_lpadc.h"

The files peripherals.h and .c are also auto generated by MCUXpresso, and all the peripherals you select during project creation are all initialised here.

For example the ADC in initialised in peripherals.c with the function ADC0_init() which is also auto generated and to my mind should more or less do everything to get the ADC up and running.

>>However, the driver has a method that pulls a “Default” structure for the ADC configuration and then initializes it && LPADC_GetDefaultConfig(&mLpadcDefaultConfigStruct);

To me the only logical place to add LPADC_GetDefaultConfig is halfway in the ADC0_init() function, but this has 2 problems:

1. peripherals.c is by default read only

2. if I go and change something in the peripherals setup tool and run "update code", any changes I made to ADC0_init() is lost

Adding LPADC_GetDefaultConfig where It made the most sense to me, had no effect, still had only 32768 in all the adc results

My feeling is that the sdk wizard / peripheral code generation tool, doesn't include include something crucial and needs to be modified? LPADC_GetDefaultConfig like you said?

Hope you can shed some licht....

[dandy1]

I've been working hard on a similar problem, using the MCUXpresso tools to set up ADC0. No matter what configuration I choose, I always get the same fixed result 2048 (12-bit) or 0 (differential) even with a potentiometer feeding varying input voltages. I, too, feel there is something missing from the tools.