Piccolo 28035 "ADC initial conversion error" and usage of all 16 ADC channels

Matthew,

Thanks for the answer. With your indicated timeline, we can't wait until this error is solved....

Yes, we would like to have all 16 channels triggered from the same source, a PWM timer underflow.

I am not sure that I fully understand the method that you describe.

I think I can only use TRIGSEL or ADCINTSOCSEL !=0, but not both !?

So do I have to reconfigure the ADC for sampling ADC0 again?

Can you describe your solution in more detail for our "same trigger source" scenario, please?

Stephan,

I apologize, there is a discontinuity between in the ADC UG in the description of the interrupt trigger(which reads as you have posted) and the figure 2 which is showing the SOCs all OR'd before being latched.  I need to confirm which is correct and either retract the above or fix the UG.

I believe that the figure is correct, in which case you could configure both the TRIGSEL and the ADCINTSOCSEL, and have your interrupt come early when SOC 14 completes.  Reason for this is that I don't want the ADC to stop inbetween global trigger from TRIGSEL and the lone ADCINTSOCSEL trigger.  Round Robin will guarantee proper order of operations.

I will try and resolve the trigger issue today and post to the forum.

Best,

Matthew

Matthew,

have you resolved the trigger issue and can post it here?

Can you also explain your suggested solution a little bit more - maybe with example code?

I am not sure how to correct the round robin pointer in your solution.

Stephan

Stephan,

Try the below, in addition to what you have already set up, keep in mind that the interrupt will be firing before the last 2 samples have completed(SOC15 and the re-triggered SOC0).  I'm counting on the ISR entry delay as well as whatever housekeeping you are doing to give enough delay before reading Result0 register.  If there is not alot of ISR overhead in your code, you'll need to make sure the ADC is finished(not busy) before reading the result0 slot.  Also assuming RR pointer is in default state from Reset when all this happens the 1st time.

"In ADC setup portion"

 AdcRegs.ADCCTL1.bit.INTPULSEPOS = 1; //adcint trigger at end of conversion

 AdcRegs.INTSEL1N2.bit.INT1E = 1;               //enable the interrupt
 AdcRegs.INTSEL1N2.bit.INT1CONT = 0;      //no continous mode
 AdcRegs.INTSEL1N2.bit.INT1SEL = 14;       // interrupt fires at EOC 14
 AdcRegs.ADCINTSOCSEL1.bit.SOC0 = 1;  // SOC0 will be triggered from INT1(plus whatever TRIGSEL is set to)
 

"Inside ADC ISR" 

AdcRegs.SOCPRICTL.bit.SOCPRIORITY = 15;    //this resets the RR pointer since it will be at SOC0 from extra trigger
 AdcRegs.SOCPRICTL.bit.SOCPRIORITY = 0;     //puts back into all RR mode/no priority, prior statement was just to re-align the pointer back to desired state

Matthew,

thanks for the example code.

It works here - although I am not sure if ADC0 is really sampled twice - it changes, but I cannot verify the second sample - right?

There are still 3 questions:
- I tried to monitor the SOCPRICTL.bit.RRPOINTER register. Even without the code inside the ADC ISR, it is always 0 after the initial SOC (monitored at the start of the ADC ISR). Why this?

- Which channel is sampled first after ADC14, ADC15 or ADC0? The RRPointer should point to ADC15, but the ADCINT will try to start SOC0!?

- Previously, I looked for ADCINTFLG.ADCINT1 that was set after ADC15 sampled to determine if all channels were sampled.
May I really use ADCCTL1.ADCBSY flag? Is this really 0 only after the last channel is sampled? From the datasheet, I would say that it is cleared after every channel for a short time until the next channel is sampled!?

Stephan,

Not sure I understand what you mean by verify the 2nd sample; for debug you could use another interrupt to verify SOC0; after the SOC0 completes 1st time enter ISR and increment counter, and re-enable ISR and see if you get a 2nd ISR entry for SOC0.  These should be far enough apart to not miss ISR.

RR Pointer points to the last converted channel; next channel in numerical order will be converted next if multiple SOCs are received.  In the case you are mentioning if it is 0, then SOC1 will be converted 1st next time you trigger all sixteen channels.  By re-writing the priority control field this should reset the RR pointer back to initial state(which offhand think is 32).  This will mean SOC0 happens 1st next go-round.  You should be able to verify this behavioral difference when you do/do not change the priority control. 

It is important to do this modification after all conversions are complete, else the RR pointer will reflect the last converted channel.  If right now you are seeing the same pointer value if you do this or not, then I suspect the ADC is not finished with conversions.  This is why I proposed looking at the BSY flag to determine if ADC is idled.  You are correct on the implementation of the BSY bit, but I am expecting it to stay set since we are pipelining subsequent conversions, i.e.  as soon as the ADC can be used again it will automatically be started since there are pending conversions; in order to maintain the DS timing there cannot be any gap between consecutive samples; that is as soon as the ADC can re-sample it will.

After ADC14 ADC15 will come next even though ADCINT re-triggers ADC0.  All triggers, software, TRIGSEL, ADCINT must still follow RR pointer order of operations.

Best,
Matthew

Ah, now I verified the RRpointer being at 0 without the modification and at 32 with modifiation (EALLOW ist needed in addition to your code snippet).

So now it seems to work fine. Thanks for the help!