• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 1120 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.

TM4C1232D5PM SPI clock stuck low

Paul B
Intellectual 810 points
Other Parts Discussed in Thread: TM4C1232D5PM

I'm using a TM4C1232D5PM and a W25Q64 SPI FLASH memory.

I read blocks of 8,192 bytes from the memory. Depending on the contents of the 8K block the SPI clock will get stuck low. I have tried different SPI cock frequencies from 1MHz to 25MHz. I've tried using the library functions and using direct hardware register access.

SSI0 initialization:

SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);
SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_3, SSI_MODE_MASTER, 1000000, 8);
SSIEnable(SSI0_BASE);

Test function:
	uint32_t j,k;
	uint32_t Data;
	DISKADDR DiskAddr;
	DiskAddr.Address = Sector << 9;
	GPIOPinWrite(GPIO_PORTA_AHB_BASE, GPIO_PIN_3, 0x00);
	SSIDataPut(SSI0_BASE,0x03); while(SSIBusy(SSI0_BASE));
	SSIDataPut(SSI0_BASE,DiskAddr.Value.Addr2); while(SSIBusy(SSI0_BASE));
	SSIDataPut(SSI0_BASE,DiskAddr.Value.Addr1); while(SSIBusy(SSI0_BASE));
	SSIDataPut(SSI0_BASE,DiskAddr.Value.Addr0); while(SSIBusy(SSI0_BASE));
	while (SSIDataGetNonBlocking(SSI0_BASE,&Data) == True);
	for(j=0;j<Height;j++) {
		for(k=0;k<Width;k++) {
			SSIDataPut(SSI0_BASE,0xFF);
			while(SSIBusy(SSI0_BASE));
			SSIDataGet(SSI0_BASE,&Data); //lsb

			SSIDataPut(SSI0_BASE,0xFF);
			while(SSIBusy(SSI0_BASE));
			SSIDataGet(SSI0_BASE,&Data); //msb

		}
	}
	GPIOPinWrite(GPIO_PORTA_AHB_BASE, GPIO_PIN_3, GPIO_PIN_3);

Any idea what might be causing this?

Thanks,

Paul.

  • 0
    Guru 117850 points

    Paul B said:
    Depending on the contents of the 8K block the SPI clock will get stuck low.

    Found that early observation of great interest/value - yet the data provided appears to avoid any/all mention/definition of that offending (or non-offending) content!  Was that by intent? 

    I've some history w/such memory devices - never have encountered "content" as a likely cause...  And - w/out any description of (offending content or that which is acceptable) nor justification for such claim  - we're likely stuck...

    Unshown is your full SSI0 initialization (specifically as relates to SSI_Clk) - beyond that - might some unwanted/unanticipated program mechanism "capture" that SSI_Clk pin - diverting it from your intended purpose? 

    One notes that SSI bus activity occurred @ 2-3 uS intervals - then the bus went, "quiet."  Some 6uS later - while MISO remained "H" - your SSI_Clk dropped.  Is that time interval repeatable?  Might such indicate some "time-out" either enforced by that slave memory - or your MCU?  And - why was the SSI sequence halted for such a period?  Such facts (absent here) may point toward resolution...

    Always - in such cases - best to repeat such tests across multiple boards - w/multiple (different) slave devices - to see if dreaded, "single board anomaly" is in play.  (i.e. HW errors never as much fun to find/fix as SW hiccups...)

  • 0 in reply to cb1_mobile
    TI__Guru**** 244380 points

    Hello Paul,

    Firstly SPI does not look at the serial data and makes any decision. Consider it to be a serial t parallel converter.

    Secondly, I took the code that you had posted (with the liberty of adding IO configuration, CS configuration as a GPIO and replacing the variables with values) and the SCLK always comes back to '1' and does not show such clock low behavior.

    Regards

    Amit Ashara

  • 0 in reply to Amit Ashara
    Intellectual 810 points

    Amit,

    Your comment that the SPI bus does not make any decision based on the data got me thinking I was looking at the wrong peripheral.

    It turns out that what I was doing with the data from the FLASH memory was causing the issue.

    I was writing it to PortC that was configured as GPIO. There is an errata for that port...

    GPIO#01 JTAG Controller Does not Ignore Transitions on PC0/TCK When it is Configured as a GPIO

    toggling on the pin may cause the device to execute unexpected JTAG instructions

    Apparently a certain sequence of data set off the errata. I masked the writing of the port to not include BIT0 and it works correctly.

    Regards,

    Paul.

  • 0 in reply to cb1_mobile
    Guru 117850 points

    cb1_mobile said:
    might some unwanted/unanticipated program mechanism "capture" that SSI_Clk pin - diverting it from your intended purpose?

    Indeed - "content of the external device" was only "indirectly" causal to your reported issue.

    Glad you found/resolved - and were gracious enough to "close" this diagnostic loop...

  • 0 in reply to Paul B
    TI__Guru**** 244380 points

    Hi Paul

    Good debug based on facts.

    Regards

    Amit