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.

TMS320F28388D: Biss Interface move to CLA Question about SPI ISR

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Tool/software:

HI,

  I was able to get the biss interface code setup and start code from TI into the CLA and everything is working so far.

  For performance reasons we would like to have the setup/start biss interface to run in the CLA on CPU2 and trigger the SPI RX ISR in CPU1.

  I would suggest not focusing on BISS, really what we need to do is have CPU2/CLA start a SPI request and have CPU1 service the SPI RX ISR.

  One issue I have bumped into is that the start operation requires flushing the SPI interface which would need to be own by CPU2 right? secondly if CPU1 needs to process the ISR and uses the SPI how does it get it back.

  Is this possible any advice on how to get it functioning would be great.

Dorion

  • Hi Dorion, 

    Thank you for the inquiry.

    So to clarify, you are wanting the SPI to be triggered by the CPU2 but have the interrupt serviced by CPU1? Out of curiosity, what is the benefit of this for your program?

    By "flushing the SPI interface", do you just mean you want to send repeated dummy data?

    In the mean time, please allow another day for me to comment on the CPU1/CPU2 owndership.

    Best Regards,

    Allison

  • HI Allison,

      Yes I need CPU2 CLA to setup the CLB's to start there process (BISS interface code we received from TI),

      Right now this code needs to be done for each start of the BISS operation. I really don't understand why. Except for resetting the FIFO's 

    static void CLA_bissc_configureSpiLength(BissCLAInterface_t *pCLABiss, uint16_t word_len, uint16_t fifo_level)
    {
        pCLABiss->SpiRegs->SPICCR.all &= ~(SPI_CCR_SPISWRESET);
        // Set the word length in the CCR register

        pCLABiss->SpiRegs->SPICCR.all = (pCLABiss->SpiRegs->SPICCR.all & ~(SPI_CCR_SPICHAR_M)) | word_len;

        // Set the RX and TX FIFO level
        // Reset the TX FIFO and enable the SPI module
        pCLABiss->SpiRegs->SPIFFTX.all = (pCLABiss->SpiRegs->SPIFFTX.all & (~SPI_FFTX_TXFFIL_M)) | (uint16_t)fifo_level;
        pCLABiss->SpiRegs->SPIFFRX.all = (pCLABiss->SpiRegs->SPIFFRX.all & (~SPI_FFRX_RXFFIL_M)) | (uint16_t)fifo_level;

        // Reset TX FIFO
        pCLABiss->SpiRegs->SPIFFTX.all  &= ~SPI_FFTX_TXFIFO;
        pCLABiss->SpiRegs->SPIFFTX.all  |= SPI_FFTX_TXFIFO;

        // Enable SPI
        pCLABiss->SpiRegs->SPICCR.all |= SPI_CCR_SPISWRESET;
    }

      I have tried to put this code elsewhere but we become inconsistent. If there is a better way of doing this so that it doesn't need to be done each time we start a read operation that would be great! Maybe I am missing something with this SPI code. If it could be removed then CLA2 doesn't have a dependency on SPI just the CLB's.

      Then when the ISR for the RX interrupt comes in I would like to service that from CPU1. Right now I am using SPIB. We have cycles on CPU1 to service this interrupt.

      CPU1 CLA is tied up with another application and the code for that cannot be move to CPU2 for performance reasons CPU2 is tight on timing right now.

      CPU1 is not as tight on timing but getting close so by moving this BISS code into the CLA (tried it on CPU1 first it worked well and increased our performance considerably) I would like to move the code over to CPU2 CLA which is not being used. But have the RX interrupts service by CPU1 which needs the data.

      Hope that makes sense.

      I also need to know that even though the CLB's are running on CPU2-CLA that there may be some hw constraints blocking me.

    Dorion

  • Hi Dorion,

    Is the message coming back to the MCU is going to change size? If not, then the function shouldn't need to be executed for each message. The level and word size can stay constant.

    Regarding if one CPU can own a peripheral but the other CPU service the interrupts: I think the ownership would need to be passed back to CPU1. Each CPU has its own PIE module, so if you want both CPUs to respond to interrupt signal, then you must independently configure the PIE modules on CPU1 and/or CPU2 to respond to it. Let me double check on this as well.

    Best Regards,

    Allison

  • So the size and length DO not change. But the BISS interface won't run unless they are configured. Which is VERY bizzare.

    I thought that you could just change ownership but I wasn't sure if something would get reset internally to the SPI when the ownership changed.

  • Sorry it won't run unless the SPI stuff is configured each time. I thought maybe something was being reset but I don't see anything.

  • Hi Dorion,

    Let me see if I understand what you are trying to do, do you want to:

    1. Have the CPU2 CLA run the start of BISS code you sent above
    2. After this is done, trigger an ISR on CPU1 to do some SPI operations 

    If so, I believe what you could do is set up a CPU2 CLA task that gets software triggered by CPU2 whenever you are wanting this BISS initialization to happen. Then. you can set up the end-of-task interrupt for the CLA task to trigger on CPU2 (which will be branched to after the task has finished all execution). In this ISR, you can software trigger an IPC interrupt back to CPU1. In this IPC ISR on CPU1, you can perform your SPI transmits/receives needed.

    In order to hand over ownership of the SPI instance to CPU1, I believe you can do something similar to the below before triggering the IPC interrupt:

    Handing over ownership of the SPI after it is initialized should not be a problem to my knowledge. If anything, you can also check in the debugger to see if this operation clears the SPI initialization registers, but I don't believe it should.

    Let me know if I am misunderstanding your use case in any way. It may also help to take a look at some of the dual core examples for F2838x in C2000ware, some of them do some similar operations.

    Best Regards,

    Delaney

  • Delaney,

      You are very close. I would like the SPI RX Interrupt Line to interrupt CPU1 instead of the CLA interrupting CPU2 to then interrupt CPU1. The CLA will only trigger a slave SPI operation and start the clocks but CPU1 will service the RX of the SPI.

      I found a way to have my CLA code not have any dependencies on the SPI (which is good) so I THINK I can keep ownership of SPI on CPU1 but just start the CLB's on cpu2.

      I believe I read that both CPU's can get the peripheral interrupts usually just one CPU will service it.  What I want to also make sure is if CPU1 has the SPI RX ISR that it also doesn't need the spi control to get the ISR. Make Sense?

      Also how do I move CLB 3 & 4 ownership over to CPU2 some command above?

    Dorion

  • Hi Dorion,

    Thanks for the feedback here. I will let Delaney comment further as well.

    In the meantime, could you expand on the nature of your SPI communication? Is F28388 is the controller/master device, what is the C2000 communicating with, and are you currently having difficulty with with SPI configuration at all? Or is it just getting the SPI interrupts figured out?

    If you want to initialize CLB ownership to CPU2, this can easily be done using SysConfig Sysctrl module or using the corresponding DriverLib:

    Best Regards,

    Allison