AM2634: Multiple ADC Issue in SDK10.0.0.35

AndreTseng

Intellectual 2555 points

Part Number: AM2634
Other Parts Discussed in Thread: CCSTUDIO, SYSCONFIG

Tool/software:

Hi expert,

Customer reports they meet issue to enable 2 ADC converter with SDK10.0. This issue did not happen with SDK9.2.

I tried and I found I got the same issue as customer report with SDK10.0.

Please refer to the test program which modify according to QSPI Flash Transfer. ADC setting is based on demo project adc_software_soc but add one more ADC converter.

qspi_flash_transfer_am263x-cc_r5fss0-0_freertos_ti-arm-clang.zip

I use ADC0 and ADC1 with internal Vref.

I aways get fail during System_init(). To be more specific, you can see the traces by CCStudio, the program always get stuck after it enable internal reference buffer for ADC3/4 SOC_enableAdcInternalReference(1, TRUE);

Question 1:

Even I did not enable REF BUFFER1 in syscfg, the code auto generated by syscfg will still enable it if you have two more ADC converters. Why? The logic of template of syscfg has issue. Reference Buffer 1 should only be enabled as ADC3 and ADC4 need it. Please refer to block diagram captured from TRM.

Can I disable this buffer to save power If I don't want to use ADC3 or ADC4? Did the template of syscfg has problem?

2. I did some more tests. I use external Vref with above project by modifying syscfg as

The program can run successfully.

I also I tried to use noRTOS demo with both Internal Verf and External Vref.

The results of both using internal and external Vref are good. The test code as below.

qspi_flash_transfer_am263x-cc_r5fss0-0_nortos_ti-arm-clang.zip

The issue should not be caused by REFBUFF setting nor Vref source. I have no idea why 2 more ADCs using Internal Vref and FreeRTOS such combination makes issue in SDK10.0.0.35.

Can you please check this problem?

Regards

Andre

11 months ago

0 AndreTseng 10 months ago

TI__Intellectual 2555 points

Any response???

Regards

Andre

0 Akshit Pareek 10 months ago in reply to AndreTseng

TI__Expert 4230 points

Hi Andre,

The API SOC_enableAdcInternalReference(uint32_t adcInstance, uint32_t enable)

/**

* \brief Enables the ADC internal reference

*

* \param adcInstance [in] ADC instance number [0 - (CSL_ADC_PER_CNT-1)]

* \param enable [in] TRUE to enable internal reference - FALSE to disable.

*/

void SOC_enableAdcInternalReference(uint32_t adcInstance, uint32_t enable);

The first argument here refers to the ADC Instance, i.e. 0 for ADC0, 1 for ADC1 and so on. NOT THE REFERENCE BUFFER NUMBER. (Therefore the API and sysconfig template seems to be correct)

The issue seems to be something else, as you mentioned in nortos config, the example is working fine. I suspect the issue might be due to some freertos configuration.

0 AndreTseng 10 months ago in reply to Akshit Pareek

TI__Intellectual 2555 points

Akshit,

Please note issue happens with 2 more ADCs using Internal Vref and FreeRTOS in SDK10.0.0.35.

Using 1ADCs using Internal Vref and FreeRTOS in SDK10.0.0.35 is still good. Please help to check what's wrong in SDK setting.

Regards

Andre

0 AndreTseng 10 months ago in reply to Akshit Pareek

TI__Intellectual 2555 points

I look into SOC_enableAdcInternalReference(uint32_t adcInstance, uint32_t enable) source code in soc.c

All ADC0, ADC1, ADC2 will set REFBUFF0.

So if ADC0 enable REFBUF but ADC1 or ADC2 disable it, the later call will overwritten previous result.

ADC0 convert result will be wrong in it does not have external Vref.

The SDK has issue.

Regards

Andre

0 Akshit Pareek 10 months ago in reply to AndreTseng

TI__Expert 4230 points

Hi Andre,

Answered on this thread: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1425961/am2634-adc-syscfg-setting-issue-in-sdk-10-0

Let's keep the discussions there. Closing this one!

0 AndreTseng 10 months ago in reply to Akshit Pareek

TI__Intellectual 2555 points

Akshit,

Another thread only discuss syscfg GUI option issue. This one should focus on why system halt when using 2 more ADCs + internal Vref with FreeRTOS.

Customer still develop code based on FreeRTOS and they need to use all ADCs. Let keep this thread until we solve this issue. Thanks.

Regards

Andre

0 Akshit Pareek 10 months ago in reply to AndreTseng

TI__Expert 4230 points

Hi Andre,

While debugging the issue, My findings are that this issue isn't caused by the ADC settings, I created a freertos example from scratch using 2 ADC's with internal vref, and settings similar to adc_soc_software example, and was able to get the conversion results without any issues.

1882.empty_am263x-cc_r5fss0-0_freertos_ti-arm-clang.zip

Please refer to the above example.

However, when I used the qspi_flash_transfer example you shared, I found out that the program is actually getting stuck at the ClockP_usleep() API

As can be seen from the above image, we are stuck at a while loop waiting for curtime to be greater than endtime. However, the changes to curtime variable here are appearing to be random, and not get more than endtime at any point. Which is causing the program to be stuck at this while loop.

Please give me sometime to do a root cause analysis on this with the Dev team, and get back to you asap.

But this information should help the customer considering the we found the real bug now.

Regards,
Akshit

0 AndreTseng 10 months ago in reply to Akshit Pareek

TI__Intellectual 2555 points

Akshit,

Based on ADC Syscfg and Internal Vref Buffer discussion we discussed before, I agree this should not be ADC issue. The test program I shared is the way I reproduce customer's issue. Developing codes which access Flash memory + multiple ADCs is normal use case. Please help to get solution. Customer still wait for us.

Regards

Andre

0 Akshit Pareek 10 months ago in reply to AndreTseng

TI__Expert 4230 points

Hi Andre,

This bug is caused due to the Clock sleep in this scenario, specific to freertos due to the clock being called before the Main task.

This will be fixed by the next release.

For now using external vref as the customer wants should still work.

Regards,
Akshit

0 AndreTseng 10 months ago in reply to Akshit Pareek

TI__Intellectual 2555 points

Akishit,

Will other scenario has the same issue - clock being called before the Main task in 10.0 SDK? It looks like using SDK10.0 have risk.

Or we should suggest customer develop code based on SDK9.2 before issue is solved?

Regards

Andre

0 Akshit Pareek 10 months ago in reply to AndreTseng

TI__Expert 4230 points

Hi Andre,

If the customer is not using anything specific to SDK10.0, they may go back to SDK9.2

Else we can discuss on mail to deliver the change to customer.

Let me know whatever works for them.

Regards,
Akshit

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2634: Multiple ADC Issue in SDK10.0.0.35