Maximum ADC Channels per Group

Olivier,

Which MCU are you working with? Please check the number of memory buffers allocated to group1. I suspect that only 16 buffers are allocated to group1 so that the ADC will stop further conversions once 16 results are written to memory. You can also check the memory overrun status flag to determine whether this is the cause.

Regards, Sunil

Oliver,

I believe Sunil is using 'buffers' to mean each entry in the FIFO, so # of buffers and FIFO size would be the same thing in his answer.

There is a TAB in HalCoGen where you can increase the size of the FIFO for each conversion group.

A FIFO size of "N" means that you are allocating storage for N results.  So if you have only a FIFO size of 16,  but you set the ADC to convert 24 channels (on the same group) you would need to be emptying the FIFO as individual conversion results are available in order to avoid a FIFO overrun.   Since you are probably not doing this, the recommendation is to make the FIFO size bigger. 

You might also want to enable the channel ID to appear in the conversion result while you are debugging this code.
This can help as you'll be able to tell which channels the conversion results come from and then you can see which channels are being dropped as you change the FIFO size.

Hello Anthony,

I was searching the forum since I am having the same issue - the 17th conversion is zero with id=0; I tried setting the FIFO size to 17 but that doesn't seem to work.

So, what was the answer for this?

Thanks,
John W.

John,

Looking at this thread - the solution was to set the FIFO size at least as large as the number of conversions that you include in the transfer group.

But I am not sure about your case.

If you read from an empty fifo location it should set bit 31 so that your result is negative.   Not sure if you've 'filtered' this out when reporting zero or not or if you've done a 32-bit read - but that is what I would check first.

Anthony,

When I had set the size to 17 - Halcogen generated this:

** - s_adcFiFoSize is used as constant table for channel selection */
static const uint32 s_adcFiFoSize[2U][3U] =
{
{16U,
17U,
16U},
{16U,
16U,
16U}
};

Which I guess is correct - not entirely sure that isn't supposed to have another 17U for ADC Group 1.

Note I have had this issue for awhile - we've been running with just the 16-channels as other bugs have taken precedence.

When I look at the array in memory after a conversion - it just reads id: 0: value: 0 - it's in the 32-but ADC structure.

In my code:

adcInit();

adcData_t ADC_Group1[24];

adcStartConversion(adcREG1,1);
while(adcIsConversionComplete(adcREG1,1)==0);
adcGetData(adcREG1,1, ADC_Group1);
if((ADC_Group1[14].value < 2731) || (ADC_Group1[14].value > 3475)) // TPS65381 DIAG_OUT Check
{
//VMON_BG is out of [2.2v 2.8v]
UART_putString(UART, "\r\nVMON_BG out of range!\r\n");
snprintf(char_lbuff, BUFF_MAX, "VMON_BG: 0x%x \r\n", ADC_Group1[14].value );
UART_putString(UART, char_lbuff);
/// while(1);
}

which is straight out of the example code.

In adcInit - this looks OK too - at least I think: (for the selected 17 channels we are using):
/** - s_adcSelect is used as constant table for channel selection */
static const uint32 s_adcSelect[2U][3U] =
{
{0x00000000U |
0x00000000U |
0x00000000U |
// 0x00000008U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U,
0x00000000U |
0x00000002U |
0x00000004U |
0x00000008U |
0x00000010U |
0x00000020U |
0x00000040U |
0x00000000U |
0x00000100U |
0x00000200U |
0x00000400U |
0x00000800U |
0x00001000U |
0x00002000U |
0x00004000U |
0x00008000U |
0x00010000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00400000U |
0x00800000U,
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U},
{0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U ,
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U,
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U |
0x00000000U}
};

Thanks,
John

Anthony,

Here's a screen shot of the ADC array - nothing after the 16th entry:

Thanks,
John W.

Hello Sunil,

Sure - see attached:

Thanks,
John W.

John,

You are configuring group1 in continuous conversion mode. Can you configure it to be in a single-sequence conversion mode? Continuous conversion mode causes issues since the software reads and ADC conversions are not synchronized. This can cause the conversion complete flag to be set erroneously, which can cause the behavior observed.

This post provides some more information on this behavior: e2e.ti.com/.../309691

Regards,
Sunil

Hello Sunil,

Disabled continuous conversion mode - see attached registers.

Result is the same - nothing after 16 results.  I tried enabling more channels - but this is doing the same thing - 
so changing that bit by itself does not seem to be the solution.

Why isn't the channel ID of 23 showing up?  That wouldn't have anything to do with a result - correct?  The CPU knows
apriori how many channel conversions are being requested - correct?

So, what is causing this?

Thanks,
John W.

John,

Something basic is missing. Can you stop the execution after the while loop waiting for the group1 conversion complete flag to be set? Please paste the conversion results memory contents and the ADC registers at this time. The group1 memory can be read directly as well. The locations are specified in the datasheet.

Sunil,

OK - I think I have attached everything you requested:

Thanks,
John W.

John,

Can you please also post the contents of the ADC1 RAM directly? This starts at address 0xFF3E0000. This memory holds the ADC1 conversion results and can be directly accessed by the software or the debugger as well.

Regards,
Sunil

Hello Sunil,

Attached:

Thanks,
John

John,

I see 16 out of 17 channels selected being stored in the ADC results' RAM, with the last result being for channel 22. There is also a group1 overrun condition flagged in the Group1 Interrupt flag register (from your earlier post). This means that you have only allotted 16 buffers for group1 results while selecting 17 channels for conversion in group1.

Please increase the number of buffers allotted to group1.

Regards,
Sunil

Sunil,

You have looked at my posts with the code, correct? The fifo size, as generated from Halogen, clearly shows 17.

Using explicit vs. vague language, I have already increased the fifo size to 17.

If this is to be done another way, please let me know with explicit instructions.

This problem remains unsolved. There is an issue with how Halogen generates code. You were convinced it was with continuous conversion and that is obviously wrong.

Please post the explicit solution to yet again what should be a simple solution.

If the fifo size has been set to 17 and this still does not work; which I have already done as clearly shown in this thread; this bug remains unsolved.

Thanks,
John W.

Sunil,

OK - I did that - and it worked until the program crashed. I had re-enabled continuous conversion mode. Everything ran OK for a little while - I can see channel 23 now - and then an exception vector was hit. At first I thought maybe something had gone wrong with my WDOG task - which I am quite happy with - but the WDOG didn't kick since the N2HET is fine and the WDOG is being serviced.

I disabled continuous conversion mode and now everything is fine. I am not sure if the thread you pointed out mentioned this or not - but running in excess of 16 FIFO channels (AND) in excess of the 16 RAM locations (which Halcogen really needs to be fixed regarding that) - results in program failure. This isn't just corrupted memory - program aborted via exception vector.

Regards,
John