• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 789 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.

RM46L852: Chaining transmission of mibSPI transfer groups

dduncan
Intellectual 315 points
Part Number: RM46L852

For our application, I'm thinking that the most sensible way to transmit multiple mibSPI transfer groups is to initiate the first TG via a software trigger (i.e., mibspiTransfer()), and then chain the remaining transmits to the transfer-completed interrupt of the previous transfer group.

Two questions:

1) Can you reasonably call mibspiTransfer() from within the user implementation of mibspiGroupNotification()?  (When I try this, about 1 in 15 attempts to transmit the 2nd TG does not occur.)

2) Does this approach seem reasonable, or am I missing the intended way to do something like this?

Some notes:

  • All TGs currently configured with Trigger Event = TRG_ALWAYS, Trigger Source = TG_DISABLED, Buffer Mode = 4, and One-shot enabled.
  • DMA is not implemented.  It may be in the future, but as I'm understanding it this is basically unrelated.

Thanks!

-David

(Edit: Added Buffer Mode setting to notes.)

  • 0
    TI__Mastermind 21425 points
    Hello,
    It should work. Please, disable the TG which is calling interrupt with writing 1 to TGENA bit in TGxCTRL register.

    Best regards,
    Miro
  • 0 in reply to Miro
    Intellectual 315 points
    I made a mistake and presumably a very important omission in my original post:
    - All of the 2nd TG transmissions do occur; they're just occasionally delayed significantly more than I had expected.
    - The first TG transfer-complete interrupt occurs while an RTI (higher priority) interrupt is active.

    So while the the initial TG transmission works during the RTI servicing, the first transfer-complete interrupt isn't serviced until after the RTI ISR is finished. Is it correct to assume that this is very simply because the processor does not (without tinkering) handle nested interrupts?

    If one wanted to allow interrupt servicing of, e.g., mibSPI, while running the main application, which is currently off of an RTI Compare interrupt, is this a good summary of the options?
    1) Switch the mibSPI interrupts from IRQ to FIQ.
    OR
    2) Don't put application code in the RTI ISR--e.g., block execution of the application until a flag is set by the RTI Compare interrupt instead (or maybe there is a better way?).

    Also, for your initial suggestion, did you mean to write a 0 to TGENA? Possibly this doesn't matter now.

    Thanks in advance!
  • 0 in reply to dduncan
    TI__Mastermind 21425 points
    Hello,
    Thanks for updating.
    You are right, Hercules MCUs does not handle nested interrupts.
    FIQ can interrupt IRQ but IRQ can't interrupt FIQ.
    Sorry, writing 0 for TGENA disables TG. In ONESHOT mode TGENA will be cleared after transfer is finished.

    Best regards,
    Miro