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.

TMS320F28386D: FSI Rx Module, Missing Register Definitions

Part Number: TMS320F28386D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Section 32.3.11 of the 'F2838x TRM [spruii0e] describes a feature of the FSI receiver core for which register definitions for configuration of said feature are missing from both the TRM and the C2000ware bitfield and driverlib implementations.
Aforementioned section describes the FSI RX module's ability to assert receiver module trigger event signals in response to one of several selectable events (such as data frame tag match).
Through figure 32-14 and table 32-11 in the TRM, we are advised that the FSI RX module embodies registers so named "RX_TRIG_CTRL_n" (where n may be 0-3) which presumably embody fields for control of behavior of corresponding event signals RX_TRIG_n.
It is naturally of great disappointment when we find registers by such names neither expounded in section 32.6 of the TRM, nor laid out in even the latest C2000ware support libraries (v5.02.00.00) for this device family, attached.
There is very limited information about these signals, although through TI's own material [spruiw4] for the 'F28003, we find reference to said register names in Table 3-1 of section 3.2 of that document.
We wish to utilize these receiver core event signals for either triggering (capture event) or synchronizing (counter reset event) the eCAP in order to affect a clock alignment scheme in a multi-node control platform employing an FSI star topology. That is, the broadcast of a particular frame by the master node which slave nodes observe with matching frame tag asserts a RX_TRIG event to capture or sync their eCAP (for example, as expounded on page 2855 of the TRM for ECAPSYNCINSEL.SEL for selection value 1F which highlights selection FSI_RXA_RX_TRIG1) which can be sent back to the master for comparison and transmission of counter adjustments. Such configuration appears not possible without correct expounding of the aforementioned RX_TRIG_CTRL_n registers of the FSI Rx cores.
Please provide a complete register description for these missing RX_TRIG_CTRL_n registers for the 'F2838x device.
  • Hi David,

    I believe this is an error in the F2838x TRM. The register is not appearing because this functionality is not available on the F2838x FSI module, but rather was added in for newer devices with a Type 2 FSI module (which includes the F28003x and F28P65x). I apologize for the confusion; I will make sure this section is removed from the F2838x TRM. 

    As for your intended application, I will consult another FSI expert and get back to you with our recommended approach.

    Best Regards,

    Delaney

  • Hi David,

    I apologize for the late follow up. After consulting with the other FSI expert, we recommend instead using the CLB module for synchronization purposes. Section 7 Event Synchronization Over FSI of the application note linked here discusses one way of doing this.

    Best Regards,

    Delaney

  • Hi Delaney,

    This question is principally about the misleading functionality described in the TRM rather than seeking advise on how to achieve synchronization.

    I would also point out that the proposed method in the app note is inadequate as it relies on "hard synchronization" which triggers a timebase synchronization event upon receipt of a particular FSI ping frame, which does not address the timebase counter discontinuity (and the potential for missed PWM AQ events when such discontinuities occur) which results when synchronization event does not correspond exactly in time when the counter would otherwise be reloaded to the same value.

    I should note we have achieved the desired outcome without the aforementioned detriments, also this is a phase-shifted PWM arrangement environment where we have achieved synchronization without carrier/AQ discontinuities (something that's been long standing stated as "not possible" on these forums).

    So, to this end, I would not suggest to mark your response as a "solution" either to the issue at hand (the misleading TRM documentation), or the issue of synchronization.

  • Hi David,

    I see, I apologize for the inconvenience. I'm glad to hear you were able to achieve the desired functionality. I will go ahead and close this thread, if you have any further questions feel free to make a new one.

    Best Regards,

    Delaney