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.
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
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
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.
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