• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1360 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.

TMS570LC4357 - SPI function and pinmux setting

Jiri Janacek
Genius 3315 points
Other Parts Discussed in Thread: HALCOGEN

Dear all,

we have faced a strange issue - compared to the behavior expected by us ;-) Let me describe our scenario:

Our application accesses to the ball E18 via HET module set as GIO output - so acting as a simple binary output.

  • Pinmux: N2HET1[08] connected to the ball E18 (default setting)
  • SPI1: this peripheral is active (just the simple SPI1, not the multibuffer variant) and sends data only via one channel (MIBSPI1SIMO[0])
  • The HalCoGen default setting of the SPI1 and MIBSPI1 port (MIBSPI1SIMO[1]) is FUNC input and that has not been originally modified by us.

  • If the ball E18 is driven to "1" via the signal N2HET1[08] (HET register for SET operation), the communication via SPI1 channel is being corrupted!
    • I am not sure whether the source of this impact is the rising edge or the high level ("1") of this signal....

  • We are very surprised of this influence - our assumption was that the E18 signal is only connected to the HET module by the pinmux moduleand cannot disturb the SPI module anyhow....

  • If we explicitly modify SPI1SIMO[1] pin mode within the SPI1 port as well as the MIBSPI1 port within HalCOGen, the SPI communication works properly.
    • SPI1SIMO[1] is manually set as the GIO output.

Code is generated by HalCoGen version 04.05.02 (but the code generated by the previous version behaves in the same way).

Please, gentlemen, any ideas or explanation of this behavior? Have I overlooked something?

Thanks and best regards,

Jiri

  • 0
    TI__Guru 68920 points
    Jiri,

    The pinmux has three sections - main one controls the *output* buffer for each pin.
    The *input* from the input buffer goes to all IPs in parallel.

    For example a pin that is mux'd between HET and GIO can be driven by HET (out) but sensed by GIO to generate an interrupt.

    There is an input mux section but this only controls which of 2 balls drives an IP input in case there is more than one choice.

    The third pinmux is 'special function' which uses the IOMM bits ofr internal 'glue' logic control at the device level.

    If you leave the SOMI[1] pin in functional mode you are enabling the parallel SPI so I would expect data from SOMI[1] to be shifted into the receive register from bit [16].

    If you change SOMI[1] to GIO then you are disabling parallel mode.

    -Anthony
  • 0 in reply to Anthony F. Seely
    Genius 3315 points

    Hi Anthony,

    thanks for your clear description of the pinmux possibilities!

    As the TRM SPNU563–May 2014 states on page 304:

    Inputs are broadcast to all multiplexed functions
    The input signals are broadcast to all modules hooked up to a terminal. The application must
    ensure that modules that are not being used in the application do not react to a change on
    their input functions. e.g. a GIO signal toggle can trigger an interrupt request, when the
    application actually is using the function multiplexed with this GIO signal.

    In summary, we have found the solution - we are happy guys ;-) Nevertheless I am still wondering how this mechanism (the corruption of SPI communication) "works" - if we reveal that, maybe we will detect another possible complication...

    You have described the situation with SOMI[1] signal - that is the input and your explanation sounds logically - this could really happen. But in our case, there is the issue with the SIMO[1] signal as should act as the output from the SPI functional view - thus this signal should not be connected to the receive (shift) register.

    Thanks for your ideas and explanation,

    Cheers and best regards,

    Jiri

  • 0 in reply to Jiri Janacek
    TI__Guru 68920 points
    Jiri,

    If there is an issue on the output side of the SPI you may see 'corruption' because of the 'biterr' - check the BITERR flag bit 28 of the SPIBUF register.

    The spi monitors its own output pins (So in master mode, SIMOx). If they do not read back the expected value this is caught by the BITERR flag. This may be causing the issue. See 25.2.16 Continuous Self-Test (Master/Slave).

    I am not sure if it stops the transfer on a biterr .. or if it finishes. if it stops then that could explain corruption based on the wrong value on SPISIMO[1].
  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points
    Looking back at some notes from a very detailed verification that was performed on the SPI in a previous version - it would not stop the transfer on a BITERR just set the flag. So not sure I can explain a corruption of receive data just from this -- unless by corruption it just means that there is an error instead of a correct completion.
  • 0 in reply to Anthony F. Seely
    Genius 3315 points
    Hi Anthony,
    thanks a lot for your deep analysis!
    I have just rough information that the data reading from the SPI slave device (an ADC) has failed - we have not measured what happened on the bus directly. Also I cannot confirm whether the BITERR flag was set or not.
    By nature (the SPI definition), the pin SIMO[1] should be recognized as the output. But this pin is set as the input within the SPI port, by default. As I have written, the explicit setting of SIMO[1] (within the SPI port setting - direction, pull-up/down,...) did help and afterwards the output GIO function driven via the HET port registers did work properly ;-)
    I think that is not necessary to waste your time by further investigation - we have found the solution, we are happy (by now ;-)).
    Thanks for your support,
    Best regards, Jiri