Compiler/TMS320F28379D: Compiler bug or driverlib bug???

Gary Brack

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software: TI C/C++ Compiler

Not sure if this is a bug with the C preprocessor, or just with Driverlib.

I imported the adc_ex2_soc_epwm example program from C2000ware 1.03 and was experimenting with it. (Using Code Composer 7.3).

At the top of the adc_ex2_soc_epwm.c file I changed:

//
// Defines
//
#define RESULTS_BUFFER_SIZE  256
//#define EX_ADC_RESOLUTION    ADC_RESOLUTION_12BIT   // Or ADC_RESOLUTION_16BIT
//#define EX_ADC_SIGNAL_MODE   ADC_MODE_SINGLE_ENDED  // Or ADC_MODE_DIFFERENTIAL
#define EX_ADC_RESOLUTION   ADC_RESOLUTION_16BIT
#define EX_ADC_SIGNAL_MODE  ADC_MODE_DIFFERENTIAL

and ran the example and at first glance it appeared to work. I watched in the debugger and ADC_setMode() definately set the ADC to 16bit differential mode.

however I was thrown off by initADCSOC(). In the editor it seemed to still gray out the changes for the ADC_RESOLUTION_16BIT like I expected. To confirm it wasn't being executed I tweaked the code to be:

//
// Function to configure ADCA's SOC0 to be triggered by ePWM1.
//
void initADCSOC(void)
{
    //
    // Configure SOC0 of ADCA to convert pin A0. The EPWM1SOCA signal will be
    // the trigger.
    //
    // For 12-bit resolution, a sampling window of 15 (75 ns at a 200MHz
    // SYSCLK rate) will be used.  For 16-bit resolution, a sampling window of
    // 64 (320 ns at a 200MHz SYSCLK rate) will be used.
    //
#if(EX_ADC_RESOLUTION==ADC_RESOLUTION_12BIT)
    ADC_setupSOC(ADCA_BASE, ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN0, 15);
#elif(EX_ADC_RESOLUTION == ADC_RESOLUTION_16BIT)
    bug;
    ADC_setupSOC(ADCA_BASE, ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN0, 64);
#endif

    //
    // Set SOC0 to set the interrupt 1 flag. Enable the interrupt and make
    // sure its flag is cleared.
    //
    ADC_setInterruptSource(ADCA_BASE, ADC_INT_NUMBER1, ADC_SOC_NUMBER0);
    ADC_enableInterrupt(ADCA_BASE, ADC_INT_NUMBER1);
    ADC_clearInterruptStatus(ADCA_BASE, ADC_INT_NUMBER1);
}

And it still compiled fine!!! (bug didn't cause the error). I am not sure if the problem is the #if() statement is malformed, or if CPP is choking on the fact that ADC_RESOLUTION_16BIT is an enumerated type.

over 8 years ago

0 Archaeologist over 8 years ago

TI__Guru* 84285 points

The preprocessor doesn't get to see enumerated types, which are a C language construct. Any unrecognized macro will be treated as 0.

For debugging this issue:
Step 1: add an \#else clause to catch unexpected cases
Step 2: add a \#warning to each branch of the \#if to tell you which branch was taken.
Step 3: add a series of tests like this:
\#if defined(ADC_RESOLUTION_12BIT)
\#warning "ADC_RESOLUTION_12BIT is defined"
\#else
\#warning "ADC_RESOLUTION_12BIT is NOT defined"
\#endif

I expect this will show that ADC_RESOLUTION_12BIT is not defined as a preprocessing macro.

0 George Mock over 8 years ago

TI__Guru**** 251550 points

Gary Brack said:
In the editor it seemed to still gray out the changes for the ADC_RESOLUTION_16BIT like I expected. To confirm it wasn't being executed I tweaked the code

Another way to understand what happens during preprocessing is to use the build option --gen_preprocessor_listing, and then inspect the resulting .rl file. Please read more about that option in the C28x compiler manual.

Thanks and regards,

-George

0 Gary Brack over 8 years ago in reply to Archaeologist

Intellectual 360 points

Thanks for your response. I wasn't sure if the preprocessor could resolve enumerated types. I guess the TI employee who wrote this code wasn't either.

I agree with you the bug is with DriverLib v1.03.0.0.

Personally I appreciate approach in "adc.h" of using enumerated types for the ADC bit resolution for purposes of future extensibility, however with this limitation of preprocessor it seems as if this might not be the best approach for portable code.

One last question. How do I get this reported over to the person/team that is maintaining/releasing that library?

0 George Mock over 8 years ago in reply to Gary Brack

TI__Guru**** 251550 points

Gary Brack said:
How do I get this reported over to the person/team that is maintaining/releasing that library?

I am moving this thread over to the C2000 forum. That's where the owners of C2000Ware (which contains driverlib) are. I'll let them know a problem has been found.

Thanks and regards,

-George

0 Christopher Chiarella over 8 years ago in reply to Gary Brack

TI__Mastermind 30255 points

Gary

Thank you, I've reported this so it can get fixed.

Best regards
Chris

C2000™︎ microcontrollers

C2000 microcontrollers forum

Compiler/TMS320F28379D: Compiler bug or driverlib bug???