• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 1536 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28375D: Connection between GPIO, CPU2, CLA of CPU2

Rob Barton
Expert 2220 points

Part Number: TMS320F28375D

Dear TI,

     I have an application running on the CLA, the CLA services the ADC's processes the values, and then generates an interrupt to CPU2, CPU2 has an interrupt service routine that just copies the data from shared CLA/CPU ram to the shared GSRam (between CPU2 and CPU1) so that CPU1 can read it as well.

     The main thread of CPU2 is just polling a GPIO pin to 'say go' , which it in turn sets a flag that the CLA can read to know to start.

    I just set the qualification bits on the inputs of the part.

GpioCtrlRegs.GPACTRL.bit.QUALPRD1 = 0x14;

GpioCtrlRegs.GPAQSEL1.bit.GPIO8 = 0x2;

and I have built in some tests in the CLA code to ensure I know when its not running fast enough, ie: not servicing all the ADCs...  I essentially set a bit when I service ADCA, B, C, D.... and if it starts servicing any of them again before it completes all 4 and calls an interrupt to CPU2, then I trigger a debugstop so I can see that it failed to complete.

When I set the above registes, which should simply set it to 1us qualification period for the GPIO input using 6 samples (200MHz part) I now have the program in CLA hitting the debug stop.

So somehow the change of qualification period affects the CLA interrupt speed...

So the question is, by changing the qualification period for the GPIO input... shouldn't that just change how often the input pin register changes value.... so from a program execution point of view, CPU2 who's main application is just continually reading the GPIO pin, should just read more values of the same thing?  Or does this somehow halt/slow down the processor as it waits for that input?  which in turn might slow down the CPU2 interrupt processing which the way I have set it up, would then affect the CLA since it has a flag that waits for the CPU2 to complete it's interrupt...

Also could you clarify the documentation under GPIO (spruHM8f)  section  sections 7.4 and subsections...  they talk about SysCLKOUt but in the registers it refers to PLLSYSCLK not SYSCLKOUT.  Also under section 2 clocking I cant find a definition of sysclkout.  If I have set the part to run at 200MHz is sysclkout 200MHz?  is pllsysclk = sysclkout?  where is it shown in the clocking section?  For now I have assumed in my calculation s of the qualification that SYSCLKOUT = 200MHz or 1/200MHz for period.

where do you list the trigger points of your GPIO to read a 1 or a 0 in terms of voltage?

the reason for the large delay is a lot of ringing is observed on the input, so the problem could be solved by addressing that in hardware, or by adding the long qualification to wait for the input to stabilize after a transition.

but either way it would be good to know why changing the GPIO qualification would impact the CPU2 execution speed.

Thanks.

  • 0
    TI__Guru** 116971 points

    Hi Rob,

    On below,

    Also could you clarify the documentation under GPIO (spruHM8f)  section  sections 7.4 and subsections...  they talk about SysCLKOUt but in the registers it refers to PLLSYSCLK not SYSCLKOUT.  Also under section 2 clocking I cant find a definition of sysclkout.  If I have set the part to run at 200MHz is sysclkout 200MHz?  is pllsysclk = sysclkout?  where is it shown in the clocking section?  For now I have assumed in my calculation s of the qualification that SYSCLKOUT = 200MHz or 1/200MHz for period.

    Yes, frq of both clocks are same. We'll update the document to avoid the confusion.

    Adding the qualification will change the timing of interrupt (when it occurs) but not the speed of interrupt handler. I am not sure how the handshake is done between CPU and CLA in your code hence can not say if this will impact the code execution.

    I did not understand the following question.

    where do you list the trigger points of your GPIO to read a 1 or a 0 in terms of voltage?

    Are you trying to trigger interrupt on transition?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Expert 2220 points
    For Q2: I meant, are these CMOS I/O, TTL, etc. to know the transition levels.

    I read that the RPT single instruction can not be interrupted, are their any other commands that might affect the ability of the CLA to interrupt the CPU2?

    Is there anything in the CPU that significantly affects it's ability to have an interrupt from the CLA?

    I'm only polling, or reading the GPIO, I am not using it to drive an interrupt. The interrupt I have on the CPU is generated by the CLA task only. It is the only interrupt.

    Q: why would the reading of GPIO affect when the Interrupt can happen? Assuming that I'm just reading the GPIO in the CPU main thread, and the CLA is calling the interrupt on the same CPU. Does the reading of GPIO, WAIT on the completion of the qualified input, or just read it at the time it's requested? ie: using figure 7-3 input qualifier clock cycles.... am I reading the output from the qualififer, AT whatever time I call for the read?

    In idea, the interrupt shouldn't know anything about what CPU2 is doing, so if CUP2 is polling a gpio, why would that 'slow down' or change when it can occur?

    Thanks.
  • 0 in reply to Rob Barton
    TI__Guru** 116971 points

    Hi Rob,

    For Q2: I meant, are these CMOS I/O, TTL, etc. to know the transition levels.

    Transition level for GPIO are provided in device datasheet. Please refer the same.

    I read that the RPT single instruction can not be interrupted, are their any other commands that might affect the ability of the CLA to interrupt the CPU2?

    Is there anything in the CPU that significantly affects it's ability to have an interrupt from the CLA?

    Please also note that interrupts are not preempted on C28x so if C28x is already servicing some interrupt then only after servicing this interrupt CPU will take CLA interrupt. Can not think of any other reason to mask/delay any interrupt.

    Q: why would the reading of GPIO affect when the Interrupt can happen? Assuming that I'm just reading the GPIO in the CPU main thread, and the CLA is calling the interrupt on the same CPU. Does the reading of GPIO, WAIT on the completion of the qualified input, or just read it at the time it's requested? ie: using figure 7-3 input qualifier clock cycles.... am I reading the output from the qualififer, AT whatever time I call for the read?

    No, reading of GPIO does not WAIT on the completion of qualified input. Read always returns the value from data register (after qualification).

    How much delay you are seeing in interrupt handling with qualification enable and how are you measuring this?

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Guru** 116971 points
    Rob, do you still see this issue?
  • 0 in reply to Vivek Singh
    Expert 2220 points

    Good timing.  8-)  We just resolved this issue yesterday.  It was external noise on the line coming into the GPIO that was causing the timing error.  We got lucky and saw it on the scope while debugging,  We switched to a special custom labview controlled setup that ensured we could control the GPIO inputs exactly and ensure it was a clean signal, and then we were able to get a perfect desired response on the 28375D without any changes to the code.  8-)  This issue is resolved.  We are now able to get perfectly timed results, the part is behaving as expected now.

    Thanks very much for the support.

  • 0 in reply to Rob Barton
    TI__Guru** 116971 points
    Thank you for the detailed update and glad to see issue is resolved.

    Regards,
    Vivek Singh