This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello TI engineer。
Our company is working on a project based on F280049C. During the debugging process of DeBug, I found that the system program can run normally during ADC interruption, but other functions in the main loop cannot run normally after ADC interruption, so I single-step operation When the problem occurs after ADC interruption, it is not a fixed situation, such as the three pictures I uploaded. I hope you can help me evaluate and see where the problem lies.
Thanks。
Hi,
Looking at the pictures, it does not tell me anything. Can you recreate the issue in C2000ware ADC example? Otherwise you can provide a trim down version of your project which we can reproduce, then we can take a look.
Thank you for your attention and reply.
I did not use the ADC sample program, and this situation is not easy to reproduce in the program I wrote.
This paragraph is my ADC interrupt function:
#ifdef CONTROL_RUNNING_ON_CPU
#pragma CODE_SECTION(ISR1,"isrcodefuncs");
#pragma INTERRUPT(ISR1, HPI)
interrupt void ISR1(void)
{
// ISR is triggered by the ADC every EPWM cycle after Vout is sampled.
// ADC should sample early enough in the cycle for the ISR to write
// the updated actuation values before the shadow loads take place.
//
//DEVICE_DELAY_US(1);
top_updateSupplyMode();
top_runIsr();
}
#endif
The logic of the problem encountered at present is very simple, that is, during the DEBUG online debugging process, the program suddenly enters a very strange state. Online debugging can see that the ADC interrupt function can run normally. When the program pointer jumps out of the interrupt, the Debug system will appear in the interface shown above, it can be found that all functions in my main loop will not run.
Hi Ford,
Can you check if the correct linker cmd file is being used in the project? Also, try running any ADC example available under C2000Ware to rule out issues other than the application code.
Thanks
Vasudha
Thank you for your reply.
After two days of investigation, I found that the above problems are related to eCAP. Since the PWM interface of F280049 has been occupied by us, I used eCAP's APWM mode to control the speed of the fan, and then found that when ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200) is set to 1200 (ECAP_O_CAP1 is 4000), there will be a pause in Debug debugging. , The function pointer jumps to void Interrupt_illegalOperationHandler(void) to show the illegal step.
Of course, I know that it is impossible to set a value for the eCAP shadow register to cause such a problem, and this problem will only occur if the value is between 1200-1450. So I continued to investigate and found that the use of the SFRA Library is related. After I shielded the SFRA_GUI_runSerialHostComms(x) function where the main loop task is 1 millisecond, there will be no DEBUG interruption. At present, the problem is only seen here. I also read SFRA_USER'S_GUIDE to explain that SFRA_GUI_runSerialHostComms(x) is to keep the SFRA GUI connection active and needs to be placed in a task of 10 milliseconds. I haven't figured out if I put the task of 1 millisecond to cause the above situation, so I am still investigating.
I hope you can help me analyze whether there are other reasons. Why call the SFRA_GUI_runSerialHostComms(x) function in a 1 millisecond task, and then use eCAP to assign a value of 1200 to ECAP_O_CAP4. There will be problems. What are the effects of these two?
Hi!
The company project program could not be uploaded, but I used your official example to reproduce the problem. I hope you can give me an explanation.
I took C2000Ware_DigitalPower_SDK_3_01_00_00/solutions/tidm_dc_dc_buck as an example. I only added the eCAP function to the buck_main.c file. The problem occurred just like the other one I responded to. The problem occurred in the following two end programs:
1、
//
// ISR1() interrupt function
//
#ifdef BUCK_CONTROL_RUNNING_ON_CPU
#pragma CODE_SECTION(ISR1,"isrcodefuncs");
#pragma INTERRUPT(ISR1, HPI)
interrupt void ISR1(void)
{
//
// ISR is triggered by the ADC every EPWM cycle after Vout is sampled.
// ADC should sample early enough in the cycle for the ISR to writebuck_F28004x.rar
// the updated actuation values before the shadow loads take place.
//
BUCK_runIsr();
ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200);
}
#endif
2、
void A2(void)
{
//
// Service SCI link for SFRA GUI
//
BUCK_SFRA_GUI_RUN_COMMS(&BUCK_sfra);
//
// Execute task A3 the next time CpuTimer0 decrements to 0
//
A_Task_Ptr = &A3;
}
If ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200); and BUCK_SFRA_GUI_RUN_COMMS(&BUCK_sfra); exist at the same time, the problem of void Interrupt_illegalOperationHandler(void) will appear in DEBUG, shielding one of the functions separately, the problem will not recur.
I also uploaded the modified program based on your official example. I hope you can help me solve it, thank you!
Hi,
Are you able to see the PWM output after you execute ECAP_setAPWMShadowCompare(ECAP1_BASE,1200)?
Best Regards,
Nirav
Hi.
This should be possible, but now there will be illegal software interruption in Debug. This is the official routine I modified. There is also the problem I mentioned. You can download it and see.
Hi,
Give us couple of days to look into this, also need to discuss with an expert on SFRA.
Best Regards,
Nirav
Hi Ford,
I am trying to replicate your problem, but I am unclear as to the steps. I took your code, built it, but I see that BUCK_CONTROL_RUNNING_ON_CPU is not defined, which means your ECAP function is not called. Maybe the project didn't import correctly, the syscfg file had an issue.
#ifdef BUCK_CONTROL_RUNNING_ON_CPU #pragma CODE_SECTION(ISR1,"isrcodefuncs"); #pragma INTERRUPT(ISR1, HPI) interrupt void ISR1(void) { // // ISR is triggered by the ADC every EPWM cycle after Vout is sampled. // ADC should sample early enough in the cycle for the ISR to write // the updated actuation values before the shadow loads take place. // BUCK_runIsr(); ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200); } #endif
I also tried importing the project from the SDK release directly and adding the ECAP function where you highlighted. But here I am unclear as to how to reproduce your issue. Do I simply run the the program and wait for something go fail or do I have to suspend/resume to see the issue?
Hello!
First of all, this is an official example provided by your C2000Ware\C2000Ware_DigitalPower_SDK_3_01_00_00_setup\C2000Ware_DigitalPower_SDK_3_01_00_00\solutions. After I redefine BUCK_CONTROL_RUNNING_ON_CPU, let the interrupt return to normal, and then the running problem still occurs. At the same time, ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200); does not necessarily have to be placed on interrupts to cause problems, and 1 millisecond tasks will also cause problems.
Secondly, maybe my English description is not very standard, which may not let you see where the problem is.I provide the illustrated steps below, you can try it.
1、Debug run the program
2、Click the resume button
3、The problem in the picture will appear after the program runs for a while.
If you disable one of the functions of ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200) and BUCK_SFRA_GUI_RUN_COMMS(&BUCK_sfra), the problem will not occur again.
I forgot to reply to you another question. Although BUCK_CONTROL_RUNNING_ON_CPU is not defined in the program code, it is defined in Properties/Predefined Symbols.
Hello again,
I tried all the same steps you outlined, but I still cannot replicate the problem you are seeing. Below you can see where I'm adding the ECAP function call. Every time I "resume" and "suspend" the program, CCS shows the code is stopped in the source code.
// // ISR1() interrupt function // #ifdef BUCK_CONTROL_RUNNING_ON_CPU #pragma CODE_SECTION(ISR1,"isrcodefuncs"); #pragma INTERRUPT(ISR1, HPI) interrupt void ISR1(void) { // // ISR is triggered by the ADC every EPWM cycle after Vout is sampled. // ADC should sample early enough in the cycle for the ISR to write // the updated actuation values before the shadow loads take place. // BUCK_runIsr(); ECAP_setAPWMShadowCompare(ECAP1_BASE, 1200); } #endif
Are you running the example code on a TI EVM? I am running it on a F280049C LaunchPad. I've imported the buck_F28004x project straight from the SDK and made the ECAP modification.
Back to your original question, as you may already know, stopping and starting code execution is intrusive. I'd advice you leverage the CCS real-time debugging mode if you are not already.
Hi!
I have found the problem because it has been running on the smallest system board in our project,After you replied to me yesterday, I tried to run on f280049c launchpad, but I didn't see the problem,After yesterday's test, I found that there should be a problem with our smallest system board layout.
Thanks again for your reply, I have found the problem, thank you!