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.

SPI clock sporadically does not transition on a TMC4123BE6PZ

We are getting some returns from the field.  I started to question whether the SPI traffic was working.  I grabbed some traces and found that sporadically the SPI clock seems to fail to transition low.  The circuit does not have any pull up or pull down resisters on any of the lines.

I find nothing in the errata for this chip about the serial clock.  I did not get any hits searching e2e.

I cannot explain why the transfers work > 99.5% of the time.

Is there experience of the SPI clock not transitioning?

The code that generates the following is included below.

    WRLS_MRF_CS_Enable();

    // Send the command
    ROM_SSIDataPut(SSI0_BASE, (UINT32) (((address >> 3) & 0x7F) | 0x80));
    ROM_SSIDataPut(SSI0_BASE, (UINT32) (((address << 5) & 0xE0)));
    while(ROM_SSIBusy(SSI0_BASE));  // Spin

    // Empty FIFO incase there is something in there
    while(ROM_SSIDataGetNonBlocking(SSI0_BASE, &temp))
    {
        // Spin until there is no more data to read.
    }

    // Drive the clock
    ROM_SSIDataPut(SSI0_BASE, 0x00); // Provide the clock
    while(ROM_SSIBusy(SSI0_BASE));  // Spin
    // Read the FIFO
    ROM_SSIDataGet(SSI0_BASE, &temp);

    toReturn = (SINT8) temp;
    WRLS_MRF_CS_Disable();

  • Hello John,

    There is no known mechanism where such a case should be possible. However, if you could share the SSI settings and the target device information, I would be able to help better.

    Regards
    Amit
  • Feel your pain.   (again)

    How sure are you that this diagnosis is your only issue?   (how do you really know?)

    Is the MCU or the peripheral "recoverable" from this condition?

    You (somehow) were able to "create" this scope trace.   Might it (greatly) assist your helpers if you detailed just how you induced the fault?   And - how do you (again really) know that this fault is (exactly) that which occurs in the field?

    Might this be ESD, or result from a noise spike, or...?   You're silent as to what's connected via SPI - and to the connection distance & medium.  Might nearby RF be an issue?

    You note (some) returns.   That's insufficient.   What percent of shipped units return - and after what (average) time-span?

    Is your board power - at all times - stable & adequate?   (again, how do you know?)

    How in-depth & how extensive was your lab testing?   Did such ever reveal in the lab?   Could it have?

    Devil in such detail - I'd (always) question your unique design first - vendor's MCU far, far later...

  • Merged snippets below on the SPI setup


    UINT32 sysCtlClock; // Port A // PA0 CAN1Rx (reserved), used for debugging UART for now and on EKS board // PA1 CAN1Tx (reserved), used for debugging UART for now and on EKS board // PA2 SSI0Clk - MiWi-SCK1 // PA3 SSI0Fss - MiWi-Fss - not used // PA4 SSI0Rx - MiWi-Rx // PA5 SSI0TX - MiWi-Tx // PA6 IN13 - MiWi-INT // PA7 IN14 - NC ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); ROM_GPIOPinTypeGPIOInput(GPIO_PORTA_BASE, GPIO_PIN_6); ROM_GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_PIN_6, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU); // WRLS will be using INT on PA6 // Use GPIO_LOW_LEVEL as interrupt may be disabled in main code, but // when re-enabled, needs to generate the interrupt ROM_GPIOIntTypeSet(GPIO_PORTA_BASE, GPIO_PIN_6, GPIO_LOW_LEVEL); ROM_IntEnable(INT_GPIOA); // Now setup the SSI0 pins ROM_GPIOPinConfigure(GPIO_PA2_SSI0CLK); //GPIOPinConfigure(GPIO_PA3_SSI0FSS); ROM_GPIOPinConfigure(GPIO_PA4_SSI0RX); ROM_GPIOPinConfigure(GPIO_PA5_SSI0TX); ROM_GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 | GPIO_PIN_2); // Set unused pins to output and set low ROM_GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_7); ROM_GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_7, 0); SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_20MHZ); sysCtlClock = SysCtlClockGet(); // Enable SSI ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0); ROM_SSIConfigSetExpClk(SSI0_BASE, sysCtlClock, SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 4000000, 8); ROM_SSIEnable(SSI0_BASE);

  • I added a single line of code to use PIOSC as the SSI clock source. The CLK signal is now clean.

    Any thoughts on this new information?
  • System clock is at 80 MHz off of a 20MHz crystal and using the PLL.

    SPI bus is at 4MHz.

    CORRECTION:  When I switched to the PIOSC, the SPI clock dropped to 800khz.  When I 'corrected' that and the source is PIOSC and SPI clock is at 4MHz, the clock corruption comes back.

  • Assuming you are supposed to get the same result back in both cases, it's not just the clock that looks odd. The bit from the peripheral is also odd. It's too short (there's no clock edge near where it is rising). Hmm, you have measure this with a logic analyser?

    Suggestion: instead of clocking 0 during the read phase clock out alternating bits. If the clock is indeed stopped you should see a DC level. The fact you don't see a DC level on MISO makes me think you might indeed have a clock.

    Robert

  • Hello John,

    When the source clock for the SPI is PIOSC, then have you changed the following configuration line so sysCtlClock is 16000000?

    ROM_SSIConfigSetExpClk(SSI0_BASE, sysCtlClock, SSI_FRF_MOTO_MODE_0,
    SSI_MODE_MASTER, 4000000, 8);

    Regards
    Amit
  • I found the issue: pilot error on the logic analyzer. Using a 8MHz logic analyzer not connected to anything to analyze a 4MHz signal is not a good move. Nyquist can make a very good 4MHz clock look bad. A 500MHz scope showed that the SPI was as expected.
  • Hello John,

    But it still does not explain the field returns

    Regards
    Amit
  • The "field returns" are not alone in remaining, "unexplained!"

    Poster has presented few facts (i.e. none) to justify his initial,"Failed SPI hunch."   Latest analysis is not particularly compelling.

    Many (real) facts were solicited - very few presented - and now (we're told) that field failures are the result of "measurement irregularity."   (phase of the moon - ruled out?...)

    Opening post (almost) competed w/"Does not Work" via uber precise, "some returns from the field."   How many?   What percent of total shipped?   Over what period?   Over what build date codes? 

    Once again - "Self-Awarded" Verify strains credibility.    (after the fact "failed measurement" is SO unlikely to describe problem cause & "fix!")