TM4C123GH6PM: SSI freezes for some reason.

Daisuke Yamazaki

Part Number: TM4C123GH6PM

Hello, I am testing the following function.
When calling this function continuously, it may freeze for waiting to receive.
This problem is solved to put "Dummy data transmission" just before "Flush receive FIFO", or remove "Flush receive FIFO" itself.
Does anyone know why?

void Sample( uint8_t *pData )
{
	uint32_t Buf;
	uint32_t i;

	
	SSIDataPut( SSI0_BASE, 0x00 );							//Send dummy data
	while( SSIDataGetNonBlocking( SSI0_BASE, &Buf ) != 0 );	//Flush receive FIFO
	
	
	for( i = 0; i < 64; i++ )
	{
		SSIDataPut( SSI0_BASE, 0x00 );						//Send dummy data
		SSIDataGet( SSI0_BASE, &Buf );						//Receive data
		*(pData++) = ( uint8_t )( Buf & 0x000000FF );		//Store data to pointer
	}
}

over 5 years ago

0 cb1_mobile over 5 years ago

Guru 117855 points

Greetings,

Humble outsider - not skilled/smart enough w/this vendor's MCUs to be able to identify a 'true - Smoking Gun.'

Daisuke Yamazaki said:
it (SPI) may freeze for waiting to receive.

Perhaps this added detail will aid 'you, vendor agents or others' - to better and/or more quickly assist:

Might the particular 'SPI Mode' have (some) bearing here? (it is not revealed)
Might (some) added 'turn-around' time between 'SSIDataPut() & SSIDataGet()' improve - ideally resolve?
Your 0x00 as 'data' produces an (unsatisfying) scope capture. Either '0xAA or 0x55' presents (instead) a regular toggling of SPI data bits - better enabling timing details.
There is no mention of (any) connection to 'MISO' (or FSS - but that appears of lesser importance) - if MISO left to 'float' - that fact alone may be your cause agent - and such inputs 'floating' (are rarely/never a good idea.)

Tag: SPI background data which (may) assist diagnosis...

0 Ralph Jacobi over 5 years ago

TI__Guru*** 135355 points

Hello Yamazaki-san,

I'm presuming the TM4C is the master here.

If so, the dummy writes are used to prompt the slave for the receiving of data. For example:

    for(ui32Index=0;ui32Index<NUM_SSI_DATA-1;ui32Index++)
    {
        SSIDataPut(SSI1_BASE,DUMMY_BYTE);
        SSIDataGet(SSI1_BASE,&pui32DataRx[ui32Index]);
    }

If the MCU is the master, then even in receive mode, the MCU must generate SPICLK. In order for the master to generate clock you still need to generate the dummy write on the MOSI even if you don't need to send data to the slave. The slave can ignore the transmitted data on the MOSI. But when the slave sees the SPICLK it will return the data on the MISO back to the master.

0 cb1_mobile over 5 years ago

Guru 117855 points

Greetings Ralph,

Staff here has a different take on poster's issue.

Daisuke Yamazaki said:
When calling this function continuously, it may freeze for waiting to receive.

While that's not explicit - it appears 'likely' that (some) SPI transfers are generated - even successful. (this based upon 'may' - which leans toward (some - even the majority) of successful SPI transfers having occurred.)

Staff believes that poster's looped call to 'SSIDataPut()' insures that the SPI clock is generated. If that proves untrue - might you kindly detail? Thank you.

Tag: SSIDataPut() (should) cause (each/every) SPI clock to, 'Sync (both) the output (and input) data' - (from and to) the MCU...

0 Daisuke Yamazaki over 5 years ago in reply to cb1_mobile

Prodigy 140 points

Thank you for following.

I have forgotten to show some conditions and explanations. They are as follows:

1. I use SPI as a master mode.
2. In many cases, this source works fine, but occasionally stops when called repeatedly. For example, it is thousands of times.
3. Using a debugger, I checked where the process stopped and found it was a receive loop in SSIDataGet.
So I think that the transmitted data was lost at some timing.

I will try your advises.

0 cb1_mobile over 5 years ago in reply to Daisuke Yamazaki

Guru 117855 points

Thank you - your response & 'Confirmation that indeed the SPI Clock (was) being generated' are appreciated. (the fact that SSIDataPut() was present w/in your code pretty much assured that the SPI Clock was produced!)

I continue in the belief that (adequate) delay (added & inserted) between SSIDataPut() and SSIDataGet() is likely to, 'Resolve your Issue.' It would be appreciated if you (more correctly) "Green Ticked/Verified" that post which Resolved your issue!"

It proves best to initially insert an 'Excessive Delay' (one longer than needed) - confirm that your issue is resolved - and only then 'methodically reduce the delay's duration.' (and as KISS notes - continue testing)

SPI robustness is aided w/Short, Direct interconnections (either pcb traces or wired) and by insuring that (especially) the SPI Clock (trace or wire) does not pass 'too close' to Noise Sources and/or other high-frequency signals.

Tag: Likely 'Honing-In' on an 'SPI-Hang'

0 Ralph Jacobi over 5 years ago in reply to cb1_mobile

TI__Guru*** 135355 points

Hello cb1,

I am not sure I agree with this assessment. The attempt here was to do a FIFO flush, not receive proper data.

The poster stated originally:

Daisuke Yamazaki said:
This problem is solved to put "Dummy data transmission" just before "Flush receive FIFO"

So that indicates the SSIDataPut was not present when the issue appeared, and as far as I am aware, even for a FIFO flush it should be present. Therefore, when Yamazaki-san added the API properly, the problem went away. So if the SSIDataPut API was not originally present, I don't see how a delay between SSIDataPut and SSIDataGet could have helped resolve this issue.

Also just as a final note, in all the posts I looked up, including from Amit, I've never seen a need for a delay between SSIDataPut and SSIDataGet. So this is the first I've heard of such.

(P.S. Hardware advice for routing is, as usual, an excellent set of guidelines)

0 cb1_mobile over 5 years ago in reply to Ralph Jacobi

Guru 117855 points

Hello Ralph,

You are far more expert than I (am) as regards (most any) peripheral's FIFO. (as long noted - investors/key clients demand that we 'Choose from a wide variety of ARM MCUs.)

I cannot follow your 'logic' in stating:

Ralph Jacobi said:
So that indicates the SSIDataPut was not present when the issue appeared

This (may) prove a language issue - yet the poster's loop - ALWAYS & ONLY provided (both) SSIDataPut & SSIDataGet.

It is suspected that the 'failure' occurred, 'During the Loop.' If that's true - then SSIDataPut() was (very well) present & well accounted! And 'Hang' was still noted!

Poster further states: "In many cases, this source works fine, but occasionally stops when called repeatedly. For example, it is thousands of times."

As to past history - is it (clear) that past posts ran for (that) K+ duration? (which may be required for the issue to reveal...)

Staff/I are 'unsure' - yet the suggestion we've offered is 'Quick & Dirty' - and (again) it appears that SSIDataPut() was always present!

0 Ralph Jacobi over 5 years ago in reply to cb1_mobile

TI__Guru*** 135355 points

Hello cb1,

My understanding from the initial post is that the customer stated the problem was solved by adding the dummy write, and then posted the now working code and inquired WHY the SSIDataPut was needed to make the code functional.

I think we can both agree a Before and After snapshot of the code would have been better.

cb1_mobile said:
Poster further states: "In many cases, this source works fine, but occasionally stops when called repeatedly. For example, it is thousands of times."

I believe the reason it was working many times is because it was a FIFO flush, and if there was not anything in the FIFO, then it would just clear past the API. But if there was data to flush out, the lack of the SSIDataPut to provide the clock to clear the data would then cause the lock up.

If I am wrong, then I invite Yamazaki-san to correct me and confirm that you were right about SSIDataPut being present when the issue occurred and we can continue to debug further starting with your delay suggestion.

0 cb1_mobile over 5 years ago in reply to Ralph Jacobi

Guru 117855 points

Hi Ralph,

That's an excellent analysis - (voted such) by (both) staff & myself.

Clearly - your suggestion of 'Failing Code' vs. 'Working Code' - presented side-by-side - will prove best.

However - we MUST return to poster's reporting, 'thousands of correct SPI transactions' - and (we) see NO OBVIOUS MEANS for your, 'Not anything in the FIFO' to have occurred. (while thousands of successes have passed...)

It should also prove helpful to learn the 'speed of the SPI Clock' - and to see if that 'played any role' in the system's 'hang.'

We are currently 'jammed' (arrived @ 04:00 today - young staff @ 05:00) yet we have 50+ (just arrived) '123 LPads - and as time allows - will implement (just) the poster's SPI Loop - (both w/& without interposed delay) - on a minimum of TEN EACH LPads... (attempting to recreate the hang - as quickly & notably as possible.) Board Leds & attached digital counter will 'signal' if such hang has occurred...)

0 cb1_mobile over 5 years ago

Guru 117855 points

Greetings Ralph,

Sorry to be so anal w/this issue - it is our intent to deploy a large number of '123 devices in one of our 'autonomous warehouse' applications. (which demands our 'high' understanding of your '123's MCU SPI function.) (another's ARM Cortex M0 could not 'match' the '123' (this time) & in (this case.)

Staff has 'zero'ed in' on poster's (specific) issue description:

Daisuke Yamazaki said:
This problem is solved to put "Dummy data transmission" just before "Flush receive FIFO", or remove "Flush receive FIFO" itself.

May we focus upon that last highlight? 'Flush receive FIFO' (which embodies the SSIDataGet() function) may be REMOVED - and in that condition - there is 'NO/ZERO' instance of "SSIDataGet()" being called in absence of the (necessary) and preceding "SSIDataPut()."

And yet - his 'Problem is (then) SOLVED! IS THAT NOT TELLING?

(We have 'Group read/re-read' the MCU manual - it is our humble opinion that 'insufficient detail describes the 'absolute handling & management' of this SPI FIFO.')

Ralph - would you be so good as to guide us/others (and of course - our poster) as to:

poster's choice of 0x00 for his 'SSIDataPut()'s data load. (We've earlier noted that - that 0x00 provides (most) limited scope feedback (i.e. flat-lines) yet might 0x00 be (commonly) found - even 'expected' - w/in the SPI FIFO (even at - especially at - unaddressed FIFO locations?)
his 'For Loop' runs a 64 count sequence - have you any idea 'How or Why' that '64' may have been chosen. (we believe that '64' - proves 'excessive.')

Thanks again for your 'insider insights & expertise' - to this level of detail - we will be launching our automated 'SPI testing' - across as many as 20 '123 LPads - w/in a few hours. Half containing the suggested delay - half w/out...

0 Ralph Jacobi over 5 years ago in reply to cb1_mobile

TI__Guru*** 135355 points

Hello cb1,

cb1_mobile said:
poster's choice of 0x00 for his 'SSIDataPut()'s data load. (We've earlier noted that - that 0x00 provides (most) limited scope feedback (i.e. flat-lines) yet might 0x00 be (commonly) found - even 'expected' - w/in the SPI FIFO (even at - especially at - unaddressed FIFO locations?)

The idea for the SSIDataPut loading is to trigger the clock, so what is loaded has no real significance. Though one thing I haven't tested is what is observed on the lines with non 0x00 values put. Not sure if there is any risk of accidentally sending a command to the other device if picking an arbitrary value like 0xAA to see activity on the line. The purpose here isn't so much to see the SPI activity but to trigger the clocking for SPIDataGet.

cb1_mobile said:
his 'For Loop' runs a 64 count sequence - have you any idea 'How or Why' that '64' may have been chosen. (we believe that '64' - proves 'excessive.')

I am not sure but if I had to guess, I'd say they had to read out 64 bytes of data. From what and for what reason I am not aware. Though with that amount of data, there could be some value in using interrupts to help handle the reception.

0 cb1_mobile over 5 years ago in reply to Ralph Jacobi

Guru 117855 points

Hello Ralph,

Thank you - staff has 'fled' & I'm 'Left to my own devices.' (insert ticking clock (bomb clock) here...)

Indeed - prior to deploying '0x55 or 0xAA' as 'SPI Data' - the slave device's sensitivity to 'either/both' must be examined. We should note too - that certain 'Slave SPI devices' MAY EMPLOY (data = 0x00) for Command/Control operations. Bottom line - Scope 'flatlines' and (still) '0x00' must be examined (just like the 2 suggested) for 'suitability.'

Do note - as a small Tech firm we cannot afford to, 'Conduct such tests 'repetitively' - rather than (just once) - when/where 'multiple suspect elements' are best visualized & exposed!' (that was taught during my past firm's, 'Going Public!')

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C123GH6PM: SSI freezes for some reason.