ChibiOS Free Embedded RTOS

I'm having a problem with some ADC code "hanging up" in the adcConvert() routine -- I'm not sure why. Sometimes it works. Actually, what I really want is something much simpler -- no DMA, just a couple of direct conversions, but that's a different matter.

#define ADC_GRP1_NUM_CHANNELS 2
#define ADC_GRP1_BUF_DEPTH 1

static adcsample_t adc_samples[ADC_GRP1_NUM_CHANNELS * ADC_GRP1_BUF_DEPTH]
__attribute__ ((section(".ram0")));
/*
* ADC Conversion group
* Mode: Linear buffer, 1 sample of 3 channels, sw triggered
* Channels: 0 (vref), 17 (temp sensor)
*/

static const ADCConversionGroup adcgrpcfg1 = {
FALSE,
ADC_GRP1_NUM_CHANNELS,
NULL,
NULL,
0, //ADC_CFGR_CONT, /* CFGR */
ADC_TR(0, 4095), /* TR1 */
{ /* SMPR[2] */
ADC_SMPR1_SMP_AN0(ADC_SMPR_SMP_47P5) ,
ADC_SMPR2_SMP_AN17(ADC_SMPR_SMP_47P5) ,
},
{ /* SQR[4] */
ADC_SQR1_SQ1_N(ADC_CHANNEL_IN0) |
ADC_SQR1_SQ2_N(ADC_CHANNEL_IN17),
0,
0,
0
}
};


void adcVDD(uint16_t *vdd100, int16_t *temp10) {
uint32_t raw;
int32_t tmp;
uint32_t vdd;

uint16_t TS_CAL1 = *((uint16_t *) 0x1FFF75A8);
uint16_t TS_CAL2 = *((uint16_t *) 0x1FFF75CA);
uint16_t VREF_CAL = *((uint16_t *) 0x1FFF75AA);

adcAcquireBus(&ADCD1);

adcStart(&ADCD1,NULL);
adcSTM32EnableVREF(&ADCD1); // enable VREF sensor
adcSTM32EnableTS(&ADCD1); // enable temperature sensor
adcConvert(&ADCD1, &adcgrpcfg1, adc_samples, ADC_GRP1_BUF_DEPTH);
adcSTM32DisableTS(&ADCD1); // disable temperature sensor
adcSTM32DisableVREF(&ADCD1); // disable VREF sensor
adcStop(&ADCD1);
adcReleaseBus(&ADCD1);

// compute vdd*100

raw = adc_samples[0];
*vdd100 = 0;
if (raw > 0) {
vdd = (300*VREF_CAL)/raw;
*vdd100 = vdd;
}

// compute temperature *10

raw = adc_samples[1];
tmp = (vdd*raw)/300;
*temp10 = (800 *(tmp - TS_CAL1))/(TS_CAL2-TS_CAL1) + 300;
}

It hangs exactly where? you need to provide info.

Verify if the DMA IRQ is triggered each time, if not then the thread is not woken.

Giovanni

Just in the adcConvert routine. If I comment that out, nothing goes wrong. Unfortunately, this is deeply embedded so getting a reliable gdb environment is tough. It's coming out of STOP2, starting the conversion, and hanging up.
Geoffrey

Couldn't you just use the Eclipse debugger? it is as easy as setting a breakpoint with a double click.

Giovanni

I think you said something important -- DMA IRQ. I have RTC events (not interrupts) -- I'm not sure about whether a pending timer event could block the DMA IRQ. The only reason I'm using RTC events is there is no support for the RTC interrupt in the STM32L4 hal.
Geoffrey

It wasn't the events/interrupts -- I figured out how to make the RTC interrupts work. It really is hanging in the convert routine, but I don't have a clue why. No, I can't use GDB in this case -- it occurs when the code wakes from STOP2 and running test code under GDB without STOP2 doesn't cause the problem.

Probably the answer is buried somewhere into the reference manual.

Giovanni

This was the line causing the hang:

osalSysPolledDelayX(OSAL_US2RTC(STM32_HCLK,20));

in ADCv2

I think the root cause has to do with how the STM32L4 handles STOP2. "mostly" configuration is preserved, but when you power down the debugger interface, the configuration to the debug trace unit is lost (usually -- depends upon decay of the register values). The following seems to work:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

osalSysPolledDelayX(OSAL_US2RTC(STM32_HCLK,20));

These stop modes have a lot of surprises !

Geoffrey