• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 1636 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

McBSP ISRs probably not keeping up with 28335 McBSP operation

ph
Prodigy 30 points

I'm getting a 0.2% probability of a transmitted 16 bit word not being received correctly when I'm sending through the McBSP at about 600 Khz (SYSCLK = LSPCLK = 150 Mhz, CLKGDV = 255). I'm trying to locate the reason for this; I need I much lower per-word error probability than that. I'm using interrupts for each word transmitted/received.

One obvious possibility is that the system (which is also doing a lot of other stuff at maybe 33% CPU load) cannot keep up with the McBSP and run the McBSP ISRs fast enough as it's sending (in fact, this seems quite likely), sometimes resulting in buffer under/overruns. Can I do anything about this except rewriting my code and trying to use DMA channels to do the memory transfers instead?

Edit: I might add that I think I'm not getting much external interference, because the distance between the DSPs (on two dev boards) is very short and it's in an office environment.

  • 0
    TI__Intellectual 2690 points

    In the 28335 data sheet, the LSPCLK is limited to 75 Mhz. This is because certain peripherals clocked off of the LSPCLK are not designed to be clocked above this frequency (in terms of clocking, I don't mean the transmit/receive clock speed - I mean the logic internal to the McBSP). 

    You mention that you are doing a lot of other stuff in the system. If you have other ISR's running in your code which are higher priority than the McBSP ISR's that could be the problem, and these are taking long enough to service that your McBSP ISR's are capturing data too late.  Would using the DMA help you in this case (to take the CPU out of the picture somewhat in reading and writing your data to a memory location?)

  • 0 in reply to CChang
    Prodigy 30 points

    Hi, thanks for the answer!

    I'll try disabling all other interrupts as a last resort to see if it makes a difference.

    I've written a DMA version but it works worse than the interrupt version for some reason...  Edit: Disabling other DMA channels didn't improve this.