• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 15 subscribers
  • Views 1523 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.

TMS570LS3137-EP: Problem with SPI1 Enable_n function

N King
Intellectual 460 points
Part Number: TMS570LS3137-EP
Other Parts Discussed in Thread: HALCOGEN

SPI1 Enable function.

I have a weird problem where the SPI port1 has been set up as a Master, with chip enable and MOSI/MISO. The ENA_n function is totally disabled, with pin left open-circuit. The four SPI pins are connected to an IGLOO FPGA, and have been shown to work on a prototype. However, the next model adds 3 MiBSPI5 lines, DMM_EN_n and 2 NHET lines as general purpose IO to the IGLOO, one of the latter being a "data available_n" handshake in to the TMS.

With the IGLOO unprogrammed, I can see that the SPI Clock and CE_n lines behave as expected. However, when programmed, the first low-going edge of CE_n is the only activity I see, with no clock, and CE_n never returns high until a processor Reset is applied. The PSU current does not rise between the good and locked states so I don't believe these lines are being forced/shorted. The processor is running, visible by CCS6.

Both TMS and IGLOO are powered from the same 3V3 supply. I cannot see the states of the IO lines, but may be able to get the IGLOO code modified to set these lines to that of an erased state. The designer says he is only using the "data available_n" line, but I've tried with this line high or low with no difference. I have used the pinmux function of HaLCoGen to "not-connect" all lines except the DMM_EN_n which is a committed pin.

I have changed the SPI port in my code to 3, which also has 'scope monitoring of the Clock and CE_n, and this works OK.

This problem has been seen on two product boards tried so far. One is part marked TMS570LS3137CCWTMEP YFC-49C73VW and the other TMS570LS3137CGWTMEP YFC-49C73VW.

Thanks

Nick

  • 0
    TI__Guru 62930 points
    Nick,
    I will try to help.
    Can you clarify what was added with MiBSPI5? Are you using MIBSPI5 as SPI device with ENan functionality (or SPI1)? Possibly you can provide a schematic of the connectivity?

    What is driving "data available_n"? What is it connected to?

    You indicate that when FPGA unprogrammed, you can see clock and CE_n lines. Is this for SPI1, or 5?

    It is difficult to understand your setup and what issues are occurring without additional details.

    Please provide more details.
    I you cannot post schematic to forum, I can contact you via email.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Intellectual 460 points

    Thanks for your reply.

    The SPI links in use are 1 and 3. All other connections are either logic inputs or outputs at 3V3, or contingency GPIO, plus one CANbus. SPI link 3 works at all times, but this is not connected to the FPGA. I can see its clock and CE/.

    The FPGA is connected variously to the SPI5, N2HET or DMM as general purpose IO. "data available_n", is wired to N2HET[10] 

    I have now managed to use the TMS Pull Select on each of the IGLOO-connected pins individually, and find that

    TMS pin E18, N2HET1[8]/MIBSPI1SIMO[1]/MII_TXD[3]

    is the culprit. Unless this pin is driven low by the TMS, a pull-up in the IGLOO overrides the TMS pull-down. Note that with E18 set as a pull-up, to ensure a good logic in voltage, the problem still occurs.

    I have checked that with pin E18 as a driven low output, the adjacent pin F18 (clock) does indeed work properly, so no pcb short.

    I have replicated this problem on my prototype, where TMS pin E18 is open-circuit. If the PSEL bit is set high, the CE_n stops low. By changing the PSEL back to low, this does not allow the CE_n to finish its cycle back to high so there is a latching function requiring Reset.

    I can send you the HALCoGeN files via e-mail if helpful.

    Nick

  • 0 in reply to N King
    TI__Guru 62930 points
    Nick,
    I think sending the files will be helpful. I will send you an email shortly.
    One question. You indicate that E18 was open on the prototype. Were you not using SPI1 for prototype? This is the master input. I guess you are not reading any data on the input, only writing?
    Thanks,
    Wade
  • 0 in reply to Wade Vonbergen
    TI__Guru**** 192326 points
    Hello Nick,

    PSEL/MISO has a very strong pull-high and pull-low on FPGA. Are you able toe disable the pull on FPGA side? How do you configure the MISO pin on MCU side? Is it configured as SPI functional pin or a GPIO pin?
  • 0 in reply to QJ Wang
    TI__Guru 62930 points
    QJ,
    I believe Nick has tested with only changed E18 status from being high or low from FPGA. This is MISO signal. Why would MISO signal impact generation of SPICLK appearing to function as SPIENA?
    Nick can you confirm that E18 is only variable to correct operation or not (low, Master generates clocks as expected: high master does not generate clocks).
    Thanks,
    Wade
  • 0 in reply to Wade Vonbergen
    Intellectual 460 points

    I have not discovered any more quirks on this SPI system. However, the comment above is not strictly correct, as E18 is configured via the PINMUX for N2HET connection so that I can bias it low, and I've seen the problem with E18 configured for nothing (HALCoGen no links): MibSPI1SIMO[1] is a secondary function. Although SPI1 doesn't generate clocks with E18 high, this state is not recovered by setting E18 low until the processor is reset. I don't know whether using the SPIGCR0  register bit would clear the problem.

  • 0 in reply to N King
    TI__Guru 62930 points
    Nick,
    QJ was able to reproduce the issue. The problem is that MibSPI1_SIMO is configured as SPI. It needs to be configured as GIO mode.
    Please confirm if this resolves your issue.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Intellectual 460 points

    I was sure that I had tried this combination... But having set the pinmux to E18: No Function, and MibSPI1_SIMO[1] to GIO, it does appear to work.

    Thanks