Setting up ADC0 for differentail input

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Setting up ADC0 for differentail input

Jump to solution
819 Views
davepfaltzgraff
Senior Contributor I

All of this is for a FRDM-K22F board, but I believe it would be similar for any of the other FRDM boards.

 

I have a differential signal connected to ADC0_DP0 (J24 pin 1) and ADC0_DM0 (J24 pin 3) and can see a good signal on the scope. However, with the attached code, I basically see the same value all the time. Can someone look over my code to see what I have set up wrong?

 

Thanks.

 

To explain the code a little, the AudioInit() routine sets up an ADC section, a DAC section and PIT0. The PIT output does two things - generate an interrupt and trigger the ADC conversion. The interrupt is used to output a value from a sine table to the DAC. That works as expected. The fact that I'm getting the ADC interrupt, tells me that the conversion is getting kicked off by the PIT.

 

What's not happening is a value representative of my input. So, at this point my conclusion is that either the MUX is not set up correctly for differential input on channel 0, or that I'm not reading the correct result register. I've checked for those and they seem OK. So, either I'm not understanding the hardware correctly or there's something else.

Original Attachment has been moved to: Audio.c.zip

Labels (1)
0 Kudos
1 Solution
578 Views
EarlOrlando
Senior Contributor II

Hello David,

I ran your code and I found that the ADC hardware trigger is disabled. With your configurations the ADC0_IRQHandler is reached just once because the conversion is triggered by software by calling the function ADC16_DRV_ConfigConvChn in the AudioInit function. I enabled the ADC hardware trigger just by changing the line "adcUserConfig.hwTriggerEnable = false;" to "adcUserConfig.hwTriggerEnable = true;" and now the ADC0_IRQHandler is reached periodically.

Also, I found a problem with the 16-bit resolution, I will look for the root problem but with the other resolutions it works ok. The problem seems to be a variable overflow.

Best regards,

Earl Orlando.

View solution in original post

0 Kudos
5 Replies
579 Views
EarlOrlando
Senior Contributor II

Hello David,

I ran your code and I found that the ADC hardware trigger is disabled. With your configurations the ADC0_IRQHandler is reached just once because the conversion is triggered by software by calling the function ADC16_DRV_ConfigConvChn in the AudioInit function. I enabled the ADC hardware trigger just by changing the line "adcUserConfig.hwTriggerEnable = false;" to "adcUserConfig.hwTriggerEnable = true;" and now the ADC0_IRQHandler is reached periodically.

Also, I found a problem with the 16-bit resolution, I will look for the root problem but with the other resolutions it works ok. The problem seems to be a variable overflow.

Best regards,

Earl Orlando.

0 Kudos
578 Views
davepfaltzgraff
Senior Contributor I

Hi (again) Earl,

OK. I got the repeated interrupts, but the values I'm getting are consistent less than 0x0F. I changed the if clause that has the NOP and I'm never hitting that breakpoint even though I'm driving the input to the limits. The background loop passes the CurrentValue to a VU meter display and it looks like my input ranges +/-7.

Might this be related to the overflow problem you mention or should I be looking for something else?

This is just an FYI and leads me to believe that you may be on to something. When I change the line from:

adcUserConfig.resolution = kAdc16ResolutionBitOfDiffModeAs16;

to:

adcUserConfig.resolution = kAdc16ResolutionBitOfDiffModeAs11;

I get the expected results from the system except that I don't get the full resolution. Although I'd like it fixed, at least I can continue working on my application

Thanks,

Dave

0 Kudos
578 Views
EarlOrlando
Senior Contributor II

Hello Dave,

That is exactly what happened to me. I looked at the ADC result register and the values are the same as the CurrentSample variable so it is not an overflow error but I think that it is a configuration error.

Please select another resolution (adcUserConfig.resolution = kAdc16ResolutionBitOfDiffModeAs16;) while I look for a solution. This problem is happening only in 16-bits mode. The other possible options are:

  • kAdc16ResolutionBitOfDiffModeAs11
  • kAdc16ResolutionBitOfDiffModeAs13
  • kAdc16ResolutionBitOfDiffModeAs9

Best regards,

Earl.

0 Kudos
578 Views
davepfaltzgraff
Senior Contributor I

Oops. See my earlier response as edited. I didn't see your response until after I posted the edits.

Going to kAdc16ResolutionBitOfDiffModeAs13 did get me the extra couple bits.

Thanks again.

0 Kudos
578 Views
davepfaltzgraff
Senior Contributor I

Hi Earl,

That was it. Previously I had been looking at the result in the background loop and just presumed that the interrupts had been occurring. A few minutes before your post, I had set the breakpoint and discovered that it was not recurring. The change you suggested got it working and I'm now looking at the data coming from the conversion.

Since it's not what I had expected, I'm curious about your other comment on the overflow.

Thanks,

Dave

0 Kudos