infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

Dave

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 11 to 17 of 17

Thread: XMC1300 VADC channels with different groups triggered by CCU8

  1. #11
    Beginner Beginner pricesc is on a distinguished road
    Join Date
    Jan 2016
    Posts
    11
    Points
    113.125
    What ADC measurement are you expecting to see on those channels/ what voltage is actually present on the pins?

    Some possibilities cross my mind:
    -If P2_PDISC bits 6 and 7 (and 8 if you are using a part where 2.7 and 2.8 share the same physical pin) are zeroed (enabling the digital input path on these pins), and you have these pins set as an input with internal pull up device active in the P2_IOCR# registers, that could be pulling the signal up, maybe?
    -If the bits are set in SHS0_GNCTR00 and SHS0_GNCTR10 for a gain factor greater than 1 (3,6,12...the gains divide the reference by this amount), and your signal is greater than that divided reference, you could be 'saturating' the conversion.

  2. #12
    New Member New Member akshatra is on a distinguished road
    Join Date
    Feb 2017
    Posts
    27
    Points
    150
    @pricesc, thanx for your kind reply. The two pins issues is solved now as per your guidance. I am trying for queue request now and facing some issues.

    Scan Request is running successfully. The only issue is there are two separate interrupts for Group 0 and Group 1.

    Realizing this I am try to implement Queue request mode with the following positions in the queue.

    Code:
    ======================================================================
    ENTRY_0        ENTRY_1        ENTRY_2        ENTRY_3        ENTRY_4      
    ======================================================================
    CH_0           CH_7             CH1           CH5             CH7
    GRP_0          GRP_0            GRP_1         GRP_1           GRP_1                         
                                 
    ======================================================================
    Please guide me for the following.
    • PWM rising edge is the trigger for the queue element positioned at zero i.e. channel_0 group_0
    • Each element in the queue should start conversion when PWM high edge is triggered.
    • The interrupt should be generated after Channel_7 Group_1 is converted i.e. whole series is converted. I need only single interrupt and read all the channels in that interrupt only.

    My confusion is
    Code:
    const XMC_VADC_QUEUE_ENTRY_t g_queue_entry_0_handle =
    {
    	.channel_num        = 0,
    	.refill_needed      = 1,
    	.external_trigger   = 0,
    	.generate_interrupt = 0,
    };
    • For each channel entry what will be the values for the following two bits.
      .external_trigger = 0,
      .generate_interrupt = 0,

    • Below bits are self explanatory, no problems in this
      .channel_num = 0,
      .refill_needed = 0,

    Rest of the registers are initialized. Only the above two bit entry is making me confuse.

    Please guide me.

    Regards,
    Tinchu
    Last edited by akshatra; May 27th, 2017 at 02:20 AM.

  3. #13
    Beginner Beginner pricesc is on a distinguished road
    Join Date
    Jan 2016
    Posts
    11
    Points
    113.125
    There are two queues, and they are group dependent. Meaning there is a queue for group 0 and a queue for group 1. You are showing channels from group 0 and 1 in the same queue, which is not possible. If you can, I would consider getting all your signals on the same group, so they can all go
    in the same queue. Of course, you mention that you have scan mode running successfully, so this should work for that as well.

    I don't use XMClib or DAVE Apps so I cannot help with initialization using those. However, if you are setting up the queue manually, and you want each conversion to be triggered by a PWM rising edge, I would think you would want the external trigger bit set in the queue register for each entry in the
    queue, and the generate interrupt bit set on the last channel in the queue.

    If you cannot get all signals you want to convert on the same group, you can route the interrupt trigger from the last queue entry of group 0 through the ERU to trigger the first entry of the queue of group 1. To do that, you need to set the enable interrupt bit on the last entry in the group 0 queue, and
    set SEV0NP bits in G0SEVNP to one of the service request lines that goes to the ERU instead of to the NVIC. Take a look at the interconnects section on the VADC...C0SR3 goes to ERU0.OGU22 and ERU0.OGU32 for example. It is pretty straightforward to get a channel of the ERU to trigger
    group 1 queue conversions...it should also be doable to AND the last conversion of Group 0 with a rising edge PWM signal to trigger Group 1. Take a look and see if it is worth figuring out.

  4. #14
    New Member New Member akshatra is on a distinguished road
    Join Date
    Feb 2017
    Posts
    27
    Points
    150
    @pricesc, thanx for your valuable guidance.

    I am trying to configure ERU with the following bits.
    • I am selecting C0SR2 - ERU0.OGU02 - Serice Request 2 of common block 0 from VADC Group 0.
    • ERU0.IOUT0 i.e. GxREQTRM to trigger group 1 of VADC.
    • ERU register EXOCON :
      1. ISS bit values selected as 0x10 i.e. ERU_OGUy2, as y is zero because I am selecting ERU0.OGU02.
      2. GP bit values selected as 0x01.

    Nothing is working so I set bit PE of EXICON and bit OCS values as 0x000.

    Still I am not getting the trigger.

    Could you please guide me what more bits/register are needed to be configured to achieve this.

    Regards
    Tinchu

  5. #15
    Beginner Beginner pricesc is on a distinguished road
    Join Date
    Jan 2016
    Posts
    11
    Points
    113.125
    The only thing I had to do to get it to work for me was set up the EXOCON register. I think the best I can do is give more details of how I did it for an example:

    -I was using OGU3 with C0SR3 as its input. I have queue for group 0 converting first The last conversion of queue group 0 was set to trigger a source event interrupt ((1 << VADC_G_QINR0_ENSI_Pos) set for the last value loaded into G0QINR0).
    -I routed that 'interrupt' to C0SR3 by setting VADC_G0->SEVNP = (0b0111<<VADC_G_SEVNP_SEV0NP_Pos).
    -I wanted the ERU to trigger the start of group 1 conversions immediately after the last conversion of group 0 finished (no waiting for a PWM edge per channel in queue, my conversions of group 0 are initially started by a PWM edge, then all channels convert in sequence without delay).
    So, I set ERU0->EXOCON[3] = (0b10<<ERU_EXOCON_ISS_Pos)|(0b0<<ERU_EXOCON_GEEN_P os)|(0b01<<ERU_EXOCON_GP_Pos). This selects input ERU_OGU32, no triggering on alternating edges, and IOUTy is activated with each activation of TOUTy.
    So, as soon as ERU_OGU32 is set high, ERU_IOUT3 rises. The interconnects section shows that IOUT3 is routed to VADC0.G1REQTRH. So, I then had the first conversion of Group 1 set to wait for a trigger event ((1<<VADC_G_QINR0_EXTER_POS) set for the first value loaded in G1QINR0)
    To complete the setup on the ADC side, I have to set VADC_G1.QMR0 and VADC_G1.QCTRL0. Specifically, G1QMR0 needs to be set to (0b01<<VADC_G_QMR0_ENGT_Pos)|(0b1<<VADC_G_QMR0_ENT R_Pos) to allow conversion requests to be issued if a valid request is in the queue register,
    and enable the use of a trigger event. G1QCTRL0.XTSEL needs to be set to 0b0111 to route ERU0.IOUT3 as the trigger source, XTmode set to 0b10 to enable trigger on rising edge, and XTWC to 1 to enable modifying the bits.

    This is what worked for me, but like I said, I only use a PWM edge to start the first conversion, so this setup will not wait for a PWM for the first conversion of the Group 1 queue. I see that there is some ANDing logic options in the ERU, so you may be able to get that functionality from the ERU,
    I just don't know the details well enough to say exactly how. You may also be able to do it with my basic ERU setup plus setting (0b10<<VADC_G_QMR0_ENGT_Pos) in G1QMR0. This adds the requirement of REQGTx = 1 to start a conversion. If you look at the ADC interconnects, several
    signals from CCU40 and CCU80 route to REQGT. I hope I maybe pointed out a detail above you may have missed. Also, sorry for my poor formatting...hope this helps.

  6. #16
    New Member New Member akshatra is on a distinguished road
    Join Date
    Feb 2017
    Posts
    27
    Points
    150
    @pricesc : thanks a lot for your kind guidance and quick response.
    With your support I have accomplished my task.

    But now as the new code is working, I just thought to see deeper in VADC queue concept and made some MCU pin high low when Interrupt is generated.

    When I am using the new code i.e PWM high pulse trigger GROUP 0(starting channel) and ERU trigger GROUP 1(starting channel) of the same queue. I got pulses on the oscilliscope.

    But when I cross verify the old code where PWM is giving trigger to GROUP 0(starting channel) and to GROUP1(starting channel), I got the same result. That's surprising for me, because I thought

    PWM first high pulse will trigger GROUP 0 and then the next pulse of PWM will trigger GROUP 1 and then resulting the generation of ISR.

    In the old code I am not using any kind of ERU trigger or any other trigger. The same PWM high pulse is triggering both GROUP 0 & 1. Is it really possible that it gives parallel trigger to both

    the groups?

    If this is the case then there is no need of ERU which I have implemented or something is there which I am missing and assuming the wrong result?

    Could you please see in this regard and reply me ASAP.

    Thank you so much for your help and knowledge sharing.

    Regard,
    Tinchu

  7. #17
    Beginner Beginner pricesc is on a distinguished road
    Join Date
    Jan 2016
    Posts
    11
    Points
    113.125
    It is hard for me to say what is going on without seeing your code and how close together your interrupts are firing. I'm pretty sure you can route the same PWM trigger to both groups.

    I thought you were trying to trigger each individual conversion on a pwm edge....i.e. Group 0 queue entry 0 converts on pwm edge 0, then Group 0 queue entry 1 converts on pwm edge 1,...group 1 queue entry n converts on pwm edge m. But it sounds like you are using the pwm edge to start the
    first conversion, and all conversions after that autoconvert in sequence (which is determined by whether or not you have the EXTR bit set in QINR 0 each queue entry). So I am a little confused on that, but I guess that is besides the point for the moment.

    Anyway, is it possible that, in your original code, you had both queues set to start converting on a PWM edge from the same channel? If so, both queues can be set to convert 'at the same time,' and as I understand it that is fine. The ADC arbiter can sequence which group gets converted when.
    If your pin toggles in interrupt are closer together in your original code than your new code, that would support what I am saying. This is all speculation without having your project in front of me, however.

    If you don't care about order of conversions, why not use the arbiter? I will say that I personally used the method I have previously described with Group 0 last conversion triggering Group 1 first conversion through the ERU because it GUARANTEED a specific order of conversions. That means
    I know all of group 0 is done converting before group 1, and so I only need ONE interrupt, when the last entry of the group 1 queue is done converting. In that one interrupt, I can store all the conversions from both groups. Something to think about.

    I hope this helped.

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.