TMS320F28388D: ADC interrupt to CLA Task Delay

Hi Adrien,

Are there any other CLA tasks enabled? If a different CLA task is being executed when the trigger comes in, it will finish the other tasks execution before branching to the ADC-triggered task.

Best Regards,

Delaney

Hi Delaney,

No, it's the only task running on CLA. That's why I expect the accurate delay I mentioned above. My task is written in C language and not in ASM language. Is it possible that the fact that it's written in C add an extra delay of about 12-13 SYSCLK due to context saving ?

Regards, 

Adrien

Hi Adrien,

Writing your task in C should not be a problem, the CLA compiler should generally be able to generate efficient code. However, is the GPIO toggle at the beginning of the task done using the GPIO_writePin() driverlib call or a direct HWREG register access? I've seen issues with the GPIO_writePin() function before on the CLA adding extra cycles. If the GPIO write is just for debugging/profliling purposes, I would suggest doing a direct write to the GPDAT register, like the below for example:

HWREG(GPIODATA_BASE + GPIO_O_GPADAT) &= 0x0001;

Best Regards,

Delaney

Hi Delaney,

I'm not using driberlib. I directly write to the GPDAT register using the regisers structures provided by TI.

So the extra-delay must come from somewhere else.

I've tried to turn off Optimisation of the compiler and to only keep the instruction to toggle the GPIO (and the instruction to clear the flag).

And it's the same result, I still measure 300ns.

Regards,

Adrien

Hi Adrien,

Delaney is currently out of office and will get back to you as soon as possible when she returns next week.

Best Regards,

Allison

Hi Adrien,

Do you have access to a debugger? Can you try stopping the debugger at the very beginning of your CLA task (using __mdebugstop();) and stepping through the disassembly to see if the GPIO write line takes more clock cycles than expected? The issue I've observed in the past with the GPIO write on CLA is that it will be stuck at one instruction for a while executing it over and over. If everything in disassembly seems to execute smoothly, this would rule out the CLA as the culprit of the delay. If that is the case, then I will loop in the XBAR and ADC experts to look into this.

Best Regards,

Delaney

Hi Delaney,

Yes I have access to the debugger. You'll find a screenshot of what you asked for. And when I assembly step into, it seems to execute smoothly.

I also attached the measure I did with a scope that illustrate what I described in my first post. I measure 986.4ns whereas I expect 926.3ns (see post 1). I measure an extra delay of 60.1ns which is about 11 SYSCLK at 190MHz. Maybe, I will accomodate with this extra-delay, I just would like to know the reason or if I miss something.

Regards, 

Adrien

Hi Adrien,

From the disassembly, I do think the 11 SYSCLK cycles are coming from the beginning of the CLA task. The compiler generates 8 MNOP instructions and 4 instructions to actually write the GPIO. Keep in mind that many instructions will take more than one SYSCLK to complete as well. If you want to confirm that all 11 cycles are happening during that time, you can use the Profile Clock feature in CCS (linked here). Start the clock when the debug intrinsic is hit, and single step through the disassembly until you get to the end of the GPIO write instructions.

You could also try to reduce the time using compiler optimizations in your project settings. But yes, I believe this is expected based on the instructions in the disassembly.

Best Regards,

Delaney