spiloopback_TivaTM4C1249NCPDT example not working

Hello,

Sorry, second paragraph, second sentance did not copy correctly.  It should be this

No data from the slave to the master!!  I checked the masterRxBuffer and found that the first byte position was 0x00 or null.  The next 25 bytes had "ello, this is the slave SPI".  No that is not a typo, the "H" was replace by a 0x00.

......

Best Regards,

Steve Mansfield

Hi Stephen,

     Did you use spi_master.c and enable internal loopback mode?

- kel

Stephen Mansfield said:

Where is this 0x00 coming from?

Feel your pain - might that 0x00 be, "resident" w/in your Master RX Buffer - prior to any SPI Slave transmission - and thus, "kill subsequent data arrival/handling?  Does that reference loopback code advise as regards proper set-up/config of any/all SPI buffers? 

As last resort - try to "seed" that buffer with a printable char. (over-riding any 0x00 presence) - and see if that "escapes" your issue...

Hello Markel,

No, I used th spiloopback_TivaTM4C1249NCPDT example which has a single executable --  spiloopback.c.  This example has 2 threads, a master thread and a slave thread.  spiloopback.c initializes both the master and slave.  The slave thread priority is higher so it gets initialized first.  Then the master is initialized and it sends the data to the slave.  You have to physically jumper MOSI, MISO, Clk, and !CS from the booster pack 1 to the booster pack 2 interface.  This might be a little confusing to some as earlier examples for other Tiva devices use the internal loopback feature and do not require you to physically connect the slave and master.  This example requires that you physically connect both the slave and master.

Best Regards,

Steve Mansfield

Hello cb1_mobile,

I checked the slaveTxBuffer just before and after it is sent and it has the correct value.  The slaveTxBuffer has an "H" in the first character position.  However, as I stated earlier an 0x00  or null gets sent as the first character to the master.  The master thread System_printf() interprets the null as an end of string and does not print anything.  However the masterTxBuffer contains 0x00 + "ello, this is slave SPI".  Somehow the slave is ignoring the first character in the slaveTxbuffer and sending a 0x00 as the first character.  I checked the readme and code again but find nothing other than the need to physically jumper MOSI, MISO, CLK, and !CS which I did.  I verified with an O-scope the correct data transfer and everything is working except I can see with the O-scope that the slave is sending a 0x00 as the first character instead of an "H".

Best Regards,

Steve Mansfield    

Stephen Mansfield said:

However the masterTxBuffer contains 0x00 + "ello, this is slave SPI".

That's a typo - is it not?  No way should the MasterTXBuffer include that lead 0x00.  (to my mind)

Experience leads me to believe that your first clocking of Master to Slave is the "cause" of that mystery 0x00.  Is it not true that data being transmitted by the Master - at the same time (but perhaps upon different clock edge) causes the Slave to output, too?  As you're plagued "only" by this initial byte - this explanation seems w/in reason.  (suspect that the Master's string termination char. {we know that to be 0x00} is the culprit here.)  Quick/easy test would see you replace that string w/in the Master TX Buffer instead with known, fixed, displayable chars. only.  (i.e. "ABC - Test") Not in string format!  (we must guard against that string terminator 0x00!)

hello cb1,

Very sorry...Type-o on my part.  The sentence should have read "However the masterRxBuffer contains 0x00 + "ello, this is slave SPI".

Like I said the first character in the masterRxBuffer contains a 0 or null.  I have confirmed this using an O-scope and looking at MOSI and MISO.  MISO is low for the first 8 bits then starts with the correct character stream "ello, this is slave SPI".  The clocking looks correct.  Especially since the next 24 characters are clocked in correctly -- the last character is a 0 or null.

I was talking to one of the other engineers on my team and he said that he remembered that when he used the TI 320F28069 MCU the first character of the master slave was not valid.  I checked the 28069 SPI documentation and it does say that.  I have checked the TM4C1294NCPDT datasheet and it does not mention anything about this.  Anyone know about an issue with the first character received by the master?

Best Regards,

Steve Mansfield

@Steve,

Appreciate your clear detail - thank you - I have bit selfish reason for seeking to aid/assist - we're evaluating a more basic TM4C against another ARM MCU - for TFT Controller w/SPI, I2C, UART & CAN I/O.  Thus - if I can solve your issue I've likely solved ours - as well.  (that's best of both worlds - I believe)

Now it remains unclear if you've attempted to eliminate the placement of a, "formal string" w/in TX_Buffer.  To me - that terminating char still is, "prime suspect" - and I don't see where you've eliminated that as a factor.  If you've a  better means to load & transfer any, "non-string" short, character array I'd like to hear it.  I continue in the belief that 0x00 has better than 50-50 odds of being the TX string terminator.  (yet - there are some who consider me bit, "pig-headed." {nerve/imprecision of them...})

Might it also be helpful to send a 2nd Slave xmsn - immediately following that failed first one - and note if the dreaded 0x00 intrudes there - as well?  And - can that 2nd xmsn again not be, "string based?"  (seek to eliminate each/every opportunity for termination byte to arrive/plague...)

Sorry to learn that - frustrating/discouraging.  We have no interest in that specific MCU - but will attempt; & report w/plain vanilla TM4C. (as well as several X brands)

To save (needless) wear/tear upon future readers - drawn here via your topic & "Verify" - perhaps you should "edit" the top of the first post - and alert readers that the thread did not properly resolve, "End well!" 

Hi,

Came across this topic because I am also trying to use SPI on the TM4C1294XL Launchpad...

Does TI have any working code? Doesn't have to be TIRTOS.

Also, can someone explain why the Console output is:

Starting the SPI loop-back example
System provider is set to SysMin. Halt the target to view any SysMin contents in ROV.
Slave SPI initialized
Master SPI initialized
Master:
Master Done

I don't understand why the Slave doesn't print anything.

Thanks,

Stephen

Hello Stephen,

Which example is this in the TivaWare?

Regards

Amit

Hi Amit,

From TI Resource Explorer:

TI-RTOS for TivaC/TM4C1294NCPDT/Driver Examples/EK-TM4C1294 Connected Launchpad/TI Target Examples/SPI Examples/SPI Loopback

Thanks,

Stephen

Hello Stephen

Is the SSI0 and SSI1 connected at the pin level on the launchpad?

Regards

Amit

Hi Amit,

spiloopback.c

slaveSpi = SPI_open(Board_SPI1, &slaveSpiParams);

masterSpi = SPI_open(Board_SPI0, NULL);

Board.h

#define Board_SPI0                  EK_TM4C1294XL_SPI2

#define Board_SPI1                  EK_TM4C1294XL_SPI3

EK_TM4C1294XL.h

/*!
* @def EK_TM4C1294XL_SPIName
* @brief Enum of SPI names on the EK_TM4C1294XL dev board
*/
typedef enum EK_TM4C1294XL_SPIName {
EK_TM4C1294XL_SPI2 = 0,  _{what is that for?}
EK_TM4C1294XL_SPI3,

EK_TM4C1294XL_SPICOUNT
} EK_TM4C1294XL_SPIName;

I assume they want to use SSI2 and SSI3 as they correspond to SPI Standard function of the BoosterPack pins. I 

I connected them at the pin level and got these results:

Starting the SPI loop-back example
System provider is set to SysMin. Halt the target to view any SysMin contents in ROV.
Slave SPI initialized
Master SPI initialized
Master:
Master Done
Slave:
Slave Done

Still no message..

Thanks,

Stephen

Hello Stephen,

I would suggest hooking a scope to the Transmit and Recieve pin of the Master to see what the transaction looks like.

BTW there is a non-RTOS version in TivaWare but it has to be updated for TM4C129. It uses the internal loopback for the SSI-0 master to send to it's own slave.

Regards

Amit

Yes, I have come across spi_master.c

Will try that if this doesn't work

I just want a simple way of implementing SPI on TIVA...

Hello Stephen,

I have already taken the example and ported it over on TM4C129. You would need to take of the System Clock Configuration function for TM4C129. The example code does it for TM4C123 and that one may cause the device to lock out. Also as for the GPIO Configuration, do have a check to see if the right IO's are being configured.

Regards

Amit

Hi Amit,

I will follow your advice and try with spi_master.c

Currently I opened an Empty project and added spi_master.c to the project.

I have a build error...

**** Build of configuration Debug for project SPIexample ****

"c:\\ti\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../spi_master.c'
'Invoking: ARM Compiler'
"c:/ti/ccsv6/tools/compiler/arm_5.1.8/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me --include_path="c:/ti/ccsv6/tools/compiler/arm_5.1.8/include" --include_path= -g --gcc --define=ccs="ccs" --define=PART_TM4C1294NCPDT --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="spi_master.pp" "../spi_master.c"
error: option --include_path is missing its parameter 'dir'
gmake: *** [spi_master.obj] Error 1
'Building file: ../tm4c1294ncpdt_startup_ccs.c'
'Invoking: ARM Compiler'
"c:/ti/ccsv6/tools/compiler/arm_5.1.8/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me --include_path="c:/ti/ccsv6/tools/compiler/arm_5.1.8/include" --include_path= -g --gcc --define=ccs="ccs" --define=PART_TM4C1294NCPDT --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="tm4c1294ncpdt_startup_ccs.pp" "../tm4c1294ncpdt_startup_ccs.c"
error: option --include_path is missing its parameter 'dir'
gmake: *** [tm4c1294ncpdt_startup_ccs.obj] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****

My Build Include Options are:

"${CG_TOOL_ROOT}/include"

"${C:\ti\TivaWare_C_Series-2.1.0.12573}"

Did I do something wrong?

EDIT: Resolved.

Include Options

"${SW_ROOT}/examples/boards/ek-tm4c1294xl"

"${SW_ROOT}"

Library FIle

"${SW_ROOT}/driverlib/ccs/Debug/driverlib.lib"

Hello Stephen,

It would be more convienent if you can zip the project and send it across as an attachment

Regards

Amit