- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Greetings,
I seperated the round robin wheel into "SOC0 to SOC6" :High Prio (SOC0-SOC5 are used, SOC6 is unused) and "SOC7 to SOC15": Round Robin Low Prio(SOC7-SOC15 are used, 3 times a size 3 burst, rince an repeat).
SOC0 to SOC5 are ALL triggered by the ePWM1 ADCSOCA event, RoundRobin-Bust (burstsize = 3) is also triggered by the same ePWM1 ADCSOCA event.
4 ADC IRQs are generated: ADC INT1 at EOC of SOC1 (for test purpose only), ADC INT2 at EOC of SOC3 (for test purpose only), ADC INT3 at EOC of SOC5 (IRQ which im primarily interested in),
ADC INT4 at EOC of SOC15 (for test purpose only)
To my question:
Im quite puzzled, because I thought the IRQs: ADC INT1, ADC INT2, ADC INT3 are always raised and my ISR is always executed at that moment the SOC EOC events are happening.
Debugging should show me something like. Download+Debug, I press start, ADC INT1 happens, ISR is called, breakpoint is hit, core is stopped and only ADCRESULT0 and ADCRESULT1 has a value other than 0x0000,
But debugging seems to show, that at that moment I finally enter the ISR for ther first time all values "SOC0 to SOC5" and "SOC7 to SOC9" are already acquired (ADCRESULT0 to ADCRESULT5 and ADCRESULT7 to ADCRESULT9 have values other than 0x0000).
What I want: ePWM1 ADCSOCA event appears an triggers HighPrio-SOCs and RR-Burst --> HighPrio-SOCs come first --> SOC0 to SOC5 are acquired --> SOC5 EOC IRQ is raised (handled by ISR) --> RR-Burst SOCs are acquired (parallel to ISR execution in the background, which to be honest I dont realy care that much). The must important thing is, that Im getting my ISR call right after SOC5 EOC happens.
But for me it looks like, that all SOCs triggered from the same event are first acquired and than my ISRs are called.
Please can somebody explain to me whats happening?
Alternatively, I tried to use Repeater1 (also triggered by the ePWM1 ADCSOCA event) to delay the trigger of the bust block until all HighPrio-SOCs are acquired. In this case the bust block is triggered by Repeater1.
But sadly a get an assert while ADC Bust initialisation ADC_setBurstModeConfig() --> ASSERT(((uint16_t)trigger & ~((uint16_t)0x1FU)) == 0U). Initialisation code is CCS Theia 1.4.1 generated. What's the problem here?
Further question is there a smarter way to get what i want. Using pure round robin acquisition doesn't work. I have to much total SOCs. On the real project I have per ADC core always 4 high prio SOCs and 7 to 9 round robin SOCs.
With best regards, Martin
Hi Joseph,
thank you very much for your reply. In fact INT_myADC0_1_ISR() was mapped to ADCINT1 (INT_ADCA1), ADCINT2 (INT_ADCA2) and ADCINT3 (INT_ADCA3). But one ISR for all three IRQs was sloppy nevertheless, so I implemented your recommendations just to be sure.
Sadly the behavior is just the same. At that moment I enter INT_myADC0_1_ISR() (which should be entered after SOC1 EOC) for the first time after pressing RUN, all other SOCs: "SOC2 to SOC5" and "SOC7 to SOC9" are already acquired.
Just to recap, what I expect with my code: ePWM1 ADCSOCA event triggers the HighPrio-SOCs and the RR-Burst --> HighPrio-SOCs should come first --> SOC0 is acquired --> SOC1 is acquired --> SOC1 EOC IRQ is raised --> INT_myADC0_1_ISR() is called --> when I break in INT_myADC0_1_ISR(), I expect register ADCRESULT0 and ADCRESULT1 to have a value other than 0x000 and all other registers ADCRESULTx to have a value of 0x0000. Which they dont have.
For me, it just looks like that all of the SOCs triggered by ePWM1 ADCSOCA will be acquired first, and than afterwards all of the IRQs raised while acquirering SOCs will be handled, which doesnt seem right.
I added all of the relevant configuration,I hope that helps. Maybe I forgot to check a box.
Furthermore, is there any chance to halt the ADC core while pending on a breakpoint. Other controllers have something like: "Stop PWM/Timer while breaking", configurable with the help of a function, a asm-directive or via a register. Maybe Im getting fooled by the debugger. My theory is, the code is just fine, but the ADC core doesnt stop at the breakpoint and continues to acquire all other SOCs and at that moment the IDE is finally notified/updated all the results are written in the ADC result registers.
I hope you can help me in this matter.
With best regards,
Martin
Hi Martin,
Ok, let's inspect some ADC register contents to see what's going on. In the Register view, can you display AdcaRegs.ADCINTOVF (ADC overflow register) as below:
Also display some Peripheral Interrupt registers specifically PieCtrlRegs.PIEIER1 and PIEIER10 and expand to show the individual fields as below:
Setting a breakpoint inside the ADC ISR halts the conversions and prevents the update of the ADC results registers.
Regards,
Joseph
Hi Joseph,
"Setting a breakpoint inside the ADC ISR halts the conversions and prevents the update of the ADC results registers."
Than it seem like, SOCs are all acquired before the first ISR is called.
Here I got the screen shots you asked me about. Once again, the program was held the fist time after pressing "Run" in ADCA_INT1_ISR INT_myADC0_1_ISR() after (supposedly) the SOC1 EOC event.
Please notice, I continued steppig through the program from breakpoint to breakpoint but a "1" in any of AdcaRegs.ADCINTOVFs register never came up.
I hope you maybe see something, which I dont.
Best regards,
Martin
Hi Joseph,
Im using the TI LauchPad kit with TMS320F28P650DK9 on it. The software Im using is based on the TI code example "adc_ex11_burst_mode_epwm" hence the name of my project.
PWM is configured like this:
PWM configuration remains the same like in "adc_ex11_burst_mode_epwm". ADC part was modified by me, just to test my intended high prio/rr setup as a prove of concept for our coming project.
To your question: No there aren't any physical signal sources connected to the channels. It's just the LauchPad as it is. All sampled adc channels are floating. Could this be the problem?
For my prove of concept, I just wanted to see if my high prio/rr setup works and if the controller behaves in a comprehensible matter. SOC channel mapping for me in this case is insignificant. I just wanted to see, that values are sampled and that the values are sampled and interrupts are raised in me intended order.
High Prio:"TRIGSEL for SOC0-5 is EPWM": My intention, TRIGSEL EPWM triggers SOC0-5, ADC samples SOC0 first, than SOC1, than SOC2, .... , than SOC5.
Round Robin: "TRIGSEL for SOC7-9 is SW (TRIGSEL=0)": My intention, BURSTTRIGSEL is also EPWM and the burst mode trigger overrides the SW TRIGSEL for SOC7-9.
I hope i could provide all the information that you need.
With best regards
Martin
Hi Joseph,
I did what you asked me to do.
But sadly it had no effect. The device/software behaves just like before. No IRQ at EOC, the first ISR only called after all SOCs were aquired.
What I did:
- Connected (just hard wired, no additional resistors used) GND to ADC_CH0 and connected 1.2V VDD to ADC_CH4 and ADC_CH5
- Pulled M4 to make sure internal VREF is used
- Addionally reconfigured ASYSCTRL in the .syscfg file to use the internal VREF of 2.5V
- Reconfigured ADC SOC in the .syscfg file to following:
High Prio: SOC0 --> CH4 (VDD), SOC1 -->CH0 (GND), SOC2 -->CH4 (VDD), SOC3 --> CH0 (GND), SOC4 -->CH4 (VDD), SOC5 -->CH0 (GND)
LowPrio RR: SOC7 --> CHN5 (VDD), SOC8 -->CHN0 (GND), SOC9 -->CHN5 (VDD),
SOC10 --> CHN0 (GND), SOC11 -->CHN5 (VDD), SOC12 -->CHN0 (GND),
SOC13 -->CHN5 (VDD), SOC14 -->CHN0 (GND), SOC15 -->CHN5 (VDD)
What I got:
ADC results made sense. For SOC0 I got 0x0793h: => 1939 --> (1939 / 4096 ~ 1.2V / 2.5V)
Other SOC showed my configured VDD -> GND -> VDD -> ... pattern.
Once again I attached all register screenshots. I hope this further helps finding the issue.
(But at first glance, register values before and after reconfiguration seem pretty even)
With best regards,
Martin
Hi Joseph,
I set up a new project based one the adc_ex11_burst_mode_epwm example and just extended it accordingly to your recommendations steps 1 to 4.
I added nothing more. For HighPrio I used SOC0 to SOC3, all SOC are set to CH4, all are triggered by ePWM1, ADCSOCA and all sample the voltage VDD = 1.2V (at tsample = 15 cycles) and with the VREF (intern) = 1.65 V as the reference.
SOC7 to SOC 15 use the old VDD, GND, VDD pattern.
Sadly, once again I see low prio SOC7 to SOC9 acquired, while breaking at ADC_INT4 ISR. This should not be happening, because ADC_INT4 ISR should be called right after SOC3 EOC, and ADC0 core should be on hold while breaking at ADC_INT4 ISR.
Once again I have the strong feeling that my high prio ISR (in this case ADC_INT4 ISR) was called after SOC9 EOC.
This theory is further reinforced by the fact that the INTx1 Flag is raised in the PIEIFR1 register.
Why am I so keen on getting my ISR called with no further delay.
For our project ePWM1 is running at 100 kHz, in center alligned, up-down-mode. Time from Z to Z = 10 µs, time from P to Z = 5 µs. We want to start the sampling of important (high prio) values the last time before calling our controller right at P: So we have 5 µs time to "sample and convert soc0 to soc3" and "processing our ac controller" and "shadow our new dutycycle" till Z arrives.
One of our SOC takes approximately 500 ns:
--> 4 (only high prio) x 500 ns = 2 µs --> 5 µs - 2 µs = 3 µs (plenty of time for processing our ac controller)
--> 7 (high prio + rr) x 500 ns = 3,5 µs --> 5 µs - 3,5 µs = 1,5 µs (not enough time for processing our ac controller)
I'd like to ask you once more, if this kind of behavior is typical for the C2000 ADC. Maybe I need to start to work on workarounds.
Please can you provide this or further information?
With best regards,
Martin
Hi Martin,
Ok, here's what I found out with the example we were running with high priority and RR burst if both high priority and RR burst conversions are triggered by EPWMSOCA:
First trigger : SOC 0–6 followed by SOC 7,8,9
Second trigger : SOC 0-6 followed by SOC 10, 11, 12
Third trigger: SOC 0-6 followed by SOC 13,14,15
Regarding to your application, the last diagram you shared makes it clear to me now what you are trying to accomplish. You are assigning high priority for the 3ph grid ac voltage conversions and load current sampling and the RR is for the DC link sampling, fan, temperature + some other monitor signals. Maybe what you can do is assign another ISR for the RR and do the calculations exclusively for each ISR. Would calculation/processing time be smaller for only the RR signals? If such is the case, maybe you can organize the conversion/ISRs as below diagram for 1 ADC:
Another option is to set P earlier such that the EPWM SOC trigger occurs earlier, maybe at a count of 1uS after Z initializes to 0. This will give plenty of time (9uS) for sampling + calculation for priority SOCs and RR for 100Khz PWM period.
Lastly, we can revisit how the 500ns conversion was derived. This has to do with the conversion mode, ADC speed and what is planned for your input network. If signal conditioning and buffering are properly taken care of, you should be able to attain the fastest sampling time and reduce the SH+conversion time further.
Best regards,
joseph
Hi Joseph,
sorry for the late late reply.
I think I found a solution for my problem. And thanks for your input.
High Prio SOCs come 2 times per period, triggered bei e.g. ePWM7 ADCSOCA (ETINTMIX = ZERO || PERIOD)
Low Prio Bursts also come 2 times per period, triggered bei e.g. ePWM8 ADCSOCA (ETINTMIX = CMPA_INCREMENT || CMPA_DECREMENT)
Period is 10 µs, so the time windows for 4 samples are 2.5 µs and I can rearrange my SOC blocks if I have to, I kinda like it. So case closed, I think.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
There is just one last thing.
Also I have found out that ADC cores really dont seem to stop if hitting debugger breakpoints.
But at least the interrupt does fire at the exact moment I need it to trigger. So, the whole time I kinda chased a problem which wasn`t really there.
I think I have the proof right here:
I build a new project.
ADCA is fed by SYSCLK at 200 MHz and runs at 50 MHz (Divider at 4)
ADCA SOC0 to SCO3 are all at15 SYSCLK cycles for sampling
ADCA SOC7 to SCO9 are all at15 SYSCLK cycles for sampling
ePWM1 also fed by SYSCLK and runs at 200 MHz (Time Base Clock Divider and High Speed Clock Divider both at 1), so ePWM1 TBCTR also doubles as a SYSCYL counter
ePWM1 period is at 1999, up counting, counter stops on next increment after emulator stop
ePWM1 CMPA is at 1000
ePWM1 ADCSOCA is triggered by CMPA_INCREMENTING, which triggers ADCA SOCs 0 to 3 and ADCA Burst SOCs 7 to 9
ePWM1 CMPA_INCREMENTING also triggeres the PWM interrupt "INT_myEPWM1_ISR"
ADCA SOC3 ECO triggeres the ADC interrupt "INT_myADC0_1_ISR"
ADCA SOC9 ECO triggeres the ADC interrupt "INT_myADC0_2_ISR"
Like always, SOC7 to SOC9 have already been sampled and converted, when the IDE showed me the "INT_myADC0_1_ISR". Because the ADCA core didn`t stop, right at the moment while hitting a breakpoint. The core continued so resolve the burst trigger, before finally stopping only after all burst SOCs where sampled and converted.
I set a breakpoint in "INT_myEPWM1_ISR". The value of ePWM1 TBCTR (at breakpoint, in ISR after event CMPA_INCREMENTING) is 0x3FBh (1019dec)
(1019dec, sadly not 100% even to the 1000 CMPA value, but the value is reasonable, because some SYSCLK cycles passed after the CMPA_INCREMENTING event and before entering the ISR)
I set a breakpoint in "INT_myADC0_1_ISR".The value of ePWM1 TBCTR (at breakpoint, in ISR after event ADCA SOC3 ECO) is 0x472h (1138dec)
(1138dec- 1019dec equals to 119dec. At first glance this could be equal to 4 times 30 SYSCLK cycles for sampling and converting SOC0 to SOC3)
I set a breakpoint in "INT_myADC0_2_ISR". The value of ePWM1 TBCTR (at breakpoint, in ISR after event ADCA SOC9 ECO) is 0x546h (1350dec)
(1350dec- 1138dec equals to 212dec. At first glance this seems of, but INT_myADC0_1_ISR takes from 0x472h to 0x530h, so 3 times 30 SYSCLK cycles for sampling and converting SOC7 to SOC9 have already past before entering this ISR)
For me, looking at the ePWM1 TBCTR values (equal to SYSCLK cycles) confirms, that the ADCA core really doesn´t stop while breaking. Especially looking at the delta between 0x3FBh (1019dec) "INT_myEPWM1_ISR" (SOC trigger) and 0x472h (1138dec) "INT_myADC0_1_ISR" (final high prio SOC EOC trigger).
There is just one thing that´s a little bit funky.
I told you that 1138dec- 1019dec equals to 119dec which is equal to 4 times 30 SYSCLK cycles for sampling and converting SOC0 to SOC3. Which sadly doesn´t add up!
Tsample for SOC0 to SOC4 are all configured at 15 SYSCLK cycles. Also ADCA clock divider is at 4, which means Tconvert is at 41 SYSCLK cycles. With channel switching (2 SYSCLK cycles) and writing to register (2 SYSCLK cycles) this should all add up to 60 SYSCLK cycles per SOC. I expected the delta to be 240dec and not 119dec. Which means the SOCs in my project are aquired to fast. I searched and searched, but couldn´t find anything I configured incorrect.
Do you have any idea what I did wrong/whats going on?
With best regards.
Martin
Hi Joseph,
I think they are looking fine.
I`m in pure up-counting mode.
(Just checking: For example, for any ePWM, base configs are 200 MHz go in, Time Base Clock Divider at 1, High Speed Clock Divider at 1
ePWM in up-mode: TBPRD at 1999 equals PWM at 100 kHz,
ePWM in up-down-mode: TBPRD at 999 also equals PWM at 100 kHz, right?)
Regards Martin
Hi Martin,
Clock prescalers are confusing 
A '0' is div by 1 and a '1' is div by 2. We generally add a 1 to get the actual divider for clock prescaler. It looks like EPWM is clocked at 100MHz before the time base divider and the high speed divider.
You can add this code in your main prior to setting up EPWM:
SysCtl_setEPWMClockDivider(SYSCTL_EPWMCLK_DIV_1);
Give this a shot and let me know. If this works we'll have to check on the clock tree tool to see why this is not obvious.
Regards,
Joseph
Hi Joseph,
thanks for the advice. It worked!
"INT_myEPWM1_ISR" comes at ePWM1 TBCTR 1036dec and "INT_myADC0_1_ISR" comes at ePWM1 TBCTR 1272dec. Round about a delta of 240dec.
It is the clock tree tool.
I commented "SysCtl_setEPWMClockDivider(SYSCTL_EPWMCLK_DIV_1);" and its backt to 100 MHz. Clock tree tool still stands at div 1 (should equal a 0 in reg).
Regards Martin
Hi Joseph,
I remember, as I created a new project, I set EPWMCLKDIV manually from /2 to /1.
Right now I created a complete new empty project again.
EPWMCLKDIV was at /2 per default. I manually set EPWMCLKDIV from /2 to /1 again, cleaned, rebuild, downloaded and debugged.
No effect (see screen shot)
Maybe this could be a Theia thing, hope this helps. ;-)
For Info I´m on Theia 1.5.0
With best regards,
Martin
Hi Martin,
Can you check if you can get to these screens and settings in your clock tree tool?
This should set the clock to EPWM equal to SYSCLK. Let me know if your code gets updated with the EPWM clock divider with this change and will feed it back to the clock tree tool folks.
Regards,
Joseph
Hi Joseph,
this is what I set up:
I selected SYSCLKDIVSEL and EPWMCLKDIV individually each and set them to /1.
Saved all, cleaned, rebuilt, downloaded and debugged.
Bonus, where the clock comes from:
But it had no effect.
-------------------------------------------------------------------------------------------------------------------------------------------
Also I tried something else (modified SYSCLKDIVSEL, LINACLKDIV andLINBCLKDIV,
saved all, cleaned, rebuilt, downloaded and debugged.), with this result:
It looks like, (for me at last) configurations in the tree config tool have no effect on code gen.
Regards Martin
Hi Martin,
As an additional step, you need to enable Device Support so that the change in clock tree will get populated in device.c file:
Ignore the other clock settings above...snippet just shows that EPWM clock divider gets changed here when Device Support is added. Check it out and let me know if this works for you.
Regards,
Joseph
Hi Joseph,
it worked! ;-) Thank you for helping me out.
------------------------------------------------------------------------------------------------------------------------------------------------------
One addition. With just adding Device Support I got redefinition linker errors. #10056
I tried https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1309451/ccstudio-sysconfig-with-adding-device-support but without success.
If someone stumbles over this thread with the same problem in mind.
You need to exclude the whole device folder and let "Use Standard Code Start Branche" tagged in.
Than it compiles without issues.
With best regards,
Martin
Hi Joseph,
sorry for the late late reply.
I think I found a solution for my problem. And thanks for your input.
High Prio SOCs come 2 times per period, triggered bei e.g. ePWM7 ADCSOCA (ETINTMIX = ZERO || PERIOD)
Low Prio Bursts also come 2 times per period, triggered bei e.g. ePWM8 ADCSOCA (ETINTMIX = CMPA_INCREMENT || CMPA_DECREMENT)
Period is 10 µs, so the time windows for 4 samples are 2.5 µs and I can rearrange my SOC blocks if I have to, I kinda like it. So case closed, I think.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
There is just one last thing.
Also I have found out that ADC cores really dont seem to stop if hitting debugger breakpoints.
But at least the interrupt does fire at the exact moment I need it to trigger. So, the whole time I kinda chased a problem which wasn`t really there.
I think I have the proof right here:
I build a new project.
ADCA is fed by SYSCLK at 200 MHz and runs at 50 MHz (Divider at 4)
ADCA SOC0 to SCO3 are all at15 SYSCLK cycles for sampling
ADCA SOC7 to SCO9 are all at15 SYSCLK cycles for sampling
ePWM1 also fed by SYSCLK and runs at 200 MHz (Time Base Clock Divider and High Speed Clock Divider both at 1), so ePWM1 TBCTR also doubles as a SYSCYL counter
ePWM1 period is at 1999, up counting, counter stops on next increment after emulator stop
ePWM1 CMPA is at 1000
ePWM1 ADCSOCA is triggered by CMPA_INCREMENTING, which triggers ADCA SOCs 0 to 3 and ADCA Burst SOCs 7 to 9
ePWM1 CMPA_INCREMENTING also triggeres the PWM interrupt "INT_myEPWM1_ISR"
ADCA SOC3 ECO triggeres the ADC interrupt "INT_myADC0_1_ISR"
ADCA SOC9 ECO triggeres the ADC interrupt "INT_myADC0_2_ISR"
Like always, SOC7 to SOC9 have already been sampled and converted, when the IDE showed me the "INT_myADC0_1_ISR". Because the ADCA core didn`t stop, right at the moment while hitting a breakpoint. The core continued so resolve the burst trigger, before finally stopping only after all burst SOCs where sampled and converted.
I set a breakpoint in "INT_myEPWM1_ISR". The value of ePWM1 TBCTR (at breakpoint, in ISR after event CMPA_INCREMENTING) is 0x3FBh (1019dec)
(1019dec, sadly not 100% even to the 1000 CMPA value, but the value is reasonable, because some SYSCLK cycles passed after the CMPA_INCREMENTING event and before entering the ISR)
I set a breakpoint in "INT_myADC0_1_ISR".The value of ePWM1 TBCTR (at breakpoint, in ISR after event ADCA SOC3 ECO) is 0x472h (1138dec)
(1138dec- 1019dec equals to 119dec. At first glance this could be equal to 4 times 30 SYSCLK cycles for sampling and converting SOC0 to SOC3)
I set a breakpoint in "INT_myADC0_2_ISR". The value of ePWM1 TBCTR (at breakpoint, in ISR after event ADCA SOC9 ECO) is 0x546h (1350dec)
(1350dec- 1138dec equals to 212dec. At first glance this seems of, but INT_myADC0_1_ISR takes from 0x472h to 0x530h, so 3 times 30 SYSCLK cycles for sampling and converting SOC7 to SOC9 have already past before entering this ISR)
For me, looking at the ePWM1 TBCTR values (equal to SYSCLK cycles) confirms, that the ADCA core really doesn´t stop while breaking. Especially looking at the delta between 0x3FBh (1019dec) "INT_myEPWM1_ISR" (SOC trigger) and 0x472h (1138dec) "INT_myADC0_1_ISR" (final high prio SOC EOC trigger).
There is just one thing that´s a little bit funky.
I told you that 1138dec- 1019dec equals to 119dec which is equal to 4 times 30 SYSCLK cycles for sampling and converting SOC0 to SOC3. Which sadly doesn´t add up!
Tsample for SOC0 to SOC4 are all configured at 15 SYSCLK cycles. Also ADCA clock divider is at 4, which means Tconvert is at 41 SYSCLK cycles. With channel switching (2 SYSCLK cycles) and writing to register (2 SYSCLK cycles) this should all add up to 60 SYSCLK cycles per SOC. I expected the delta to be 240dec and not 119dec. Which means the SOCs in my project are aquired to fast. I searched and searched, but couldn´t find anything I configured incorrect.
Do you have any idea what I did wrong/whats going on?
With best regards.
Martin
