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

Issue with RM48L952DZWT on SPI1

Hugues Lepage
Prodigy 120 points
Other Parts Discussed in Thread: HALCOGEN

Hello,

Today, I spent all my day on a bug with SPI1. Each transaction lead to a BITERRFLG. Never saw that error on SPI3 and SPI4. After extensive investigation, finally found that if pin E18 is programmed as USB1.OverCurrent, and its state is 1, then BITERRFLG is systematically set after a transaction. If USB1.OverCurrent is low, then no BITERRFLG.

I found it because on the HDK, if USB1 is disabled, bit 17 of PC2 (DIN) is 0, and on my board is 1… Turned USB1 ON on the HDK: bit 17 is 1 and each transaction started to set BITERRFLG.

The function that HALCoGen generates doesn’t send any data on SPI if any of the flags are set. I easily worked that around by clearing BITERRFLG before any call to SPI functions.

Now that I understanding the behavior of SPI1, I am convinced that my hardware is okay.

Am-I the first one to find this bug? I found nothing in the Errata.

Thanks and regards,

Hugues

  • 0
    TI__Guru 68920 points
    Hugues,

    This SPI has a feature called BITERR where it monitors that data (through I/O loopback) for it's own transmitter and notifies you through the BITERR flag if there is a mismatch.

    Ok so now if the SPI1 is trying to transmit data on pin E18, but in the pinmux you have E18 selected as being controlled by the USB1 module - then this error would be real and you would expect it.

    The reason is that the SPI will still 'listen' to E18 and since USB1 overcurrent is probably quasi-static very soon you'll have tried to transmit the opposite of whatever the overcurrent state is and you'll get the BITERR flag.

    Now, this is predicated on ' if the SPI1 is trying to transmit data on pin E18'

    The way that you chose this is somewhat indirect. In the SPI PORT control if you have selected SPISIMO[1] / SPISOMI[1] as "SPI" and not "GIO" then you are putting the SPI into the 2 pin parallel mode and it will be attempting to transmit on both of it's data pins.

    (You should also see only 1/2 as many clocks generated per transfer in this mode ... side note)

    So please make sure that you have SPISIMO[1] and SPISOMI[1] configured as GIO then try again.

    Thanks and Best Regards,
    Anthony
  • 0 in reply to Anthony F. Seely
    Prodigy 120 points
    Anthony,

    Reading back my message, I noticed I missed some information!

    I am sending on SPI1SIMO[0] on F19, configured as SPI, no pinmux required.
    With E18 configured as USB1.OverCurrent through pinmux, and if the signal on E18 is high, then every transmit on SPI1 leads to BITERR. If E19 input is low, no BITERR.

    Signal on F19 is exactly as expected on the oscilloscope. It appears that there is some cross-connection between E18 signal and BITERR logic on F19.

    Regards,

    Hugues
  • 0 in reply to Hugues Lepage
    TI__Guru 68920 points
    Hugues,

    Yes because pin E18 is: N2HET1[8]/MIBSPI1SIMO[1]/MII_TXD[3]/USB1.OverCurrent

    When you select USB1.OverCurrent in the pinmux this gives the USB port control of the pin's output buffer.

    The input buffer however continues to feed N2HET1[8] (as input), the MIBSPI1SIMO[1] signal and the MII_TXD[3] signal.

    So BITERR would occur if the SPI is monitoring MIBSPI1SIMO[1].

    What we need to check is not just the pinmux but also in the SPI, the SPIPMCTRL PMODEx[1:0] bits.. you want these all to be '0'. And SPIPC0 needs to have 0x0101xxxx in it so that only one SIMO and one SOMI pin are enabled.

    Note - I believe in the HalCoGen GUI the PMODE choice is implicitly made based on whether or not you select SIMO[1] and SOMI[1] as GIO or SPI.
  • 0 in reply to Anthony F. Seely
    Prodigy 120 points
    Anthony,

    Indeed, I had to select SOMI1 and SIMO1 as GIO instead of SPI... Did not see this issue with SPI3 and SPI4, since these only have one SOMI/SIMO pair.

    Thanks for fixing this.

    Regards,

    Hugues