TMS320F280049: SPIA Slave Mode MISO Glitching

Stuart Baker

Part Number: TMS320F280049

I'm working with a customer using SPIA in slave mode. The SPI clock rate is 12.5MHz, and the SYSCLK frequency is 100 MHz. We are observing a large transient in the system that sometimes causes the MISO state machine to skip one or more data bits when shifting data. We do not see the issue on the MOSI data. The incidence rate goes up when the board is put in a thermal chamber and heated (but still within spec).

We have placed all of the SPI lines on a scope using high impedance, low capacitance, probes, and they look reasonable clean, including the SPI clock. We started by looking into layout, and as a result have the following E2E thread that addresses possible issues with VDD and VDDIO decoupling capacitors:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/885049

Just to eliminate the possibility of an external clock issue, I asked the customer to disable their external oscillator (they are using a TTL output oscillator, not a crystal), and derive the system clocks from the internal 10 MHz RC resonator. When they do this, the SPI MISO state machine glitch disappears completely.

We did identify a possible path in the layout where the large transient could plausibly couple into the oscillator, and the customer is going to probe the oscillator output to have a look at it. Note that the rest of the device seems to be working fine, and the only place we see an issue is in the SPI MISO data.

I've asked the customer to send me some information on the oscillator and to send me their clock subsystem configuration settings when using the external oscillator. I'm waiting on this information.

We are looking for ideas on possible failure modes given what we know. Any ideas are welcome, including ideas to test out in the lab.

Thanks,

Stuart

over 5 years ago

0 Genatco over 5 years ago

Guru 56093 points

Stuart Baker said:
I'm working with a customer using SPIA in slave mode

Which SPI is the master and slave? All GPIO pins default to synchronous mode and must be qualified async mode for non synchronous serial devices.

If not qualified to be System clocked, bits may be missed by target application reading FIFO.

// GPIO17->SPIA-SDO for J1/J2 connection
GPIO_setMasterCore(17, GPIO_CORE_CPU1);
GPIO_setPinConfig(GPIO_17_SPISOMIA);
GPIO_setDirectionMode(17, GPIO_DIR_MODE_IN);
GPIO_setPadConfig(17, GPIO_PIN_TYPE_STD);
GPIO_setQualificationMode(17, GPIO_QUAL_ASYNC);

// GPIO16->SPIA-SDI for J1/J2 connection
GPIO_setMasterCore(16, GPIO_CORE_CPU1);
GPIO_setPinConfig(GPIO_16_SPISIMOA);
GPIO_setDirectionMode(16, GPIO_DIR_MODE_OUT);
GPIO_setPadConfig(16, GPIO_PIN_TYPE_STD);
GPIO_setQualificationMode(16, GPIO_QUAL_ASYNC);

0 Stuart Baker over 5 years ago in reply to Genatco

TI__Genius 10690 points

As indicated in the posting title and description body, SPIA is being used in slave mode.

Should these ASYNC qualifications be applied to all four SPI signals (SDO, SDI, CLK, and STE)?

Thanks,

Stuart

0 Manoj Santha Mohan over 5 years ago in reply to Stuart Baker

TI__Guru 55700 points

Stuart,

Yes, all the SPI pins should be configured in ASYNC mode.

Regards,

Manoj

0 Manoj Santha Mohan over 5 years ago

TI__Guru 55700 points

Stuart,

Can you share the SPI bus waveform which shows the efforts of transient on the following signals:-

1) VDD / VDDIO (In the other post, you had mentioned about large unintended loop paths on VDD / VDDIO wrt ground)

2) Input clock the SYSPLL.

3) SPI bus signals: SPICLK / MOSI / MISO / SPISTE pin

Based on the information provided, I get a feeling that this is a board layout issue which has already been identified and fixing the board layout issue will fix the problem.

Regards,

Manoj

0 Genatco over 5 years ago in reply to Stuart Baker

Guru 56093 points

Stuart Baker said:
As indicated in the posting title and description body, SPIA is being used in slave mode.

>>I'm working with a customer using SPIA in slave mode.

Is the customer actually using SPIA in slave mode or is the connected device a slave, to the target (master) and a more common mode.

Also an arbitrary statement as both sides of the connection use SPIA port. Alternatively the (targets SPIA) port can be a slave and device a master depending on how the target SPIA port was configured. Posting a short snip of the SPIA configuration helps define the conversation thread more clearly.