KSDK SPI Driver Issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KSDK SPI Driver Issue

1,450 Views
aeroengineer1
Contributor II

I am sure that I am just missing something stupidly simple, but I cannot see it.  It may be because I have stayed up too late the last few nights soldering up breakout boards.  I am trying to get SPI communications working on a KL03Freedom board working.  I am using the SPI_DRV_MasterTransfer() function.  This is a processor expert project and the SPI comms are setup through the fsl_spi component.

 

When I use the SPI_DRV_MasterTransfer, I can get the clock line working, though I cannot get any data out.  I have just tryed to set it such that it is sending and receiving a simple Byte.  Once this is achieved, then I will get into an array.  I have it such that the code is to turn the light green if it gets the proper response from the connected device, or red if it does not get the proper response.  I have confirmed by presetting the proper response value and commenting out the code for SPI_DRV_MasterTransfer() that this portion is working as expected (there was no doubt that it would, but just in case I was doing something dumb, I wanted to be sure).

 

Any help would be appreciated, thanks!

 

Adam

/* ################################################################### **     Filename    : main.c **     Project     : Test **     Processor   : MKL03Z32VFK4 **     Version     : Driver 01.01 **     Compiler    : GNU C Compiler **     Date/Time   : 2015-05-09, 14:30, # CodeGen: 0 **     Abstract    : **         Main module. **         This module contains user's application code. **     Settings    : **     Contents    : **         No public methods ** ** ###################################################################*/ /*! ** @file main.c ** @version 01.01 ** @brief **         Main module. **         This module contains user's application code. */         /*! **  @addtogroup main_module main module documentation **  @{ */         /* MODULE main */   /* Including needed modules to compile this module/procedure */ #include "Cpu.h" #include "Events.h" #include "clockMan1.h" #include "osa1.h" #include "pin_mux.h" #include "spiCom2.h" #if CPU_INIT_CONFIG   #include "Init_Config.h" #endif /* User includes (#include below this line is not maintained by Processor Expert) */  /*lint -save  -e970 Disable MISRA rule (6.3) checking. */  unsigned int testing = 0; unsigned int count = 0; unsigned int clockOld; unsigned int clockNew = 0; unsigned int pwmCounterValue; unsigned int spiRead; unsigned int i = 0; uint8_t spiBufferValues = 0b00100000;        //Who Am I address uint8_t spiReadBufferValues = 0b10110001;    //Proper response  int main(void) /*lint -restore Enable MISRA rule (6.3) checking. */ {   /* Write your local variable definition here */   unsigned int count = 0;    /*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/   PE_low_level_init();   /*** End of Processor Expert internal initialization.                    ***/    /* Write your code here */   SPI_DRV_MasterTransfer(FSL_SPICOM2,NULL,&spiBufferValues,&spiReadBufferValues,1);    //Blue Led   //TPM1_C1V = 65535;                    //Set Blue LED On   //LPTMR0_CNR = 65535;    for(;;)   {       //count = LPTMR0_CNR;       //TPM1_C1V = 65535;       if (spiReadBufferValues == 0b10110001)    //If response is valid, light the Green LED       {           TPM0_C0V = 65535;        //Green           TPM0_C1V = 1;            //Red           TPM1_C0V = 1;            //Blue       }       else                                        //If response invalid, light Red LED       {           TPM0_C0V = 1;            //Green           TPM0_C1V = 65535;        //Red           TPM1_C0V = 1;            //Blue       }   }    /*** Don't write any code pass this line, or it will be deleted during code generation. ***/   /*** RTOS startup code. Macro PEX_RTOS_START is defined by the RTOS component. DON'T MODIFY THIS CODE!!! ***/   #ifdef PEX_RTOS_START     PEX_RTOS_START();                  /* Startup of the selected RTOS. Macro is defined by the RTOS component. */   #endif   /*** End of RTOS startup code.  ***/   /*** Processor Expert end of main routine. DON'T MODIFY THIS CODE!!! ***/   for(;;){}   /*** Processor Expert end of main routine. DON'T WRITE CODE BELOW!!! ***/ } /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/  /* END main */ /*! ** @} */ /* ** ################################################################### ** **     This file was created by Processor Expert 10.5 [05.21] **     for the Freescale Kinetis series of microcontrollers. ** ** ################################################################### */
Labels (1)
0 Kudos
9 Replies

796 Views
marek_neuzil
NXP Employee
NXP Employee

Hello Adam,

You are using Processor Expert and fsl_spi component. There is important to properly set the fsl_spi component and the initialization. You must properly set (enable) the

Master configuration, enable the Auto Initialization and set the Master configuration in the initialization (the Processor Expert generate spi device initialization code as a part of the PE_low_level_init() function - fsl_spi driver initialization functions are called in the ComponentsInit() function).

You must also enable and select used pins (these pins are disabled by default). See the screenshot below:

pastedImage_0.png

Best Regards,

Marek Neuzil

0 Kudos

796 Views
aeroengineer1
Contributor II

Also note that I did try to manually initialize the SPI module using the SPI_DRV_MasterInit() function.  I can confirm that I was able to change the the clock polarity, but still was not able to get data out on the bus.

0 Kudos

796 Views
marek_neuzil
NXP Employee
NXP Employee

Adam,

I have checked the reference manual, FRDM-KL03Z scheme and everything is OK (PTA6 and PTA7 pins are not used by other devices). I have also created the target board application that work properly - SCK and MOSI signals are OK (data are sent). See the following picture of the board and used pins:

pastedImage_3.png

You can check the attached application that works on my FRDM-KL03Z target board properly.

When you connect PTA6 and PTA7 by a wire data are sent and received correctly in the application (see the connection on the picture above).

Note:

I am not using Tabs view in the Component Inspector window and therefore the view is different. If you want to use the same tree view navigate into Component Inspector window, open the menu and uncheck the Tabs view, see the screenshot below:

pastedImage_0.png

Best Regards,

Marek Neuzil

0 Kudos

796 Views
aeroengineer1
Contributor II

I did find some related information for the Blocking version of the function and the delays between bits in this link.  I will see if compiler optimization settings can help with this, though I will also dig into the code to see if there is any delays in the function that can be reduced.

0 Kudos

796 Views
marek_neuzil
NXP Employee
NXP Employee

Adam,

I have checked the driver that is designed for transferring block of data. I have measured the delay between two characters when the bock of 10 bytes is sent and there were 100us delay only (I have used the modified demo application).

There is CPU time consuming interrupt service routine and the SPI does not have any FIFO buffer. If you want to reduce the delay between characters you can increase the bus clock (and core clock). When I have used bus clock 24MHz and core clock 48MHz, the delay is about 10us.

Note:

The bus clock and core clock frequency can be set in the fsl_clock_manager component in the project. Open the Component Inspector of the component, select the MIRC in the MCG mode property and set the Core clock to 48MHz and Bus clock to 24MHz, see the screenshot below:

pastedImage_6.png

If you need a simple SPI driver for your application and you cannot use high bus/core clock frequencies you can use Init_SPI and fsl_spi_hal components to write a simple driver that meets requirements of your application.

Best Regards,

Marek Neuzil

0 Kudos

796 Views
aeroengineer1
Contributor II

Marek,

Sorry for the late reply.  I will have more information to post on this issue later.  Needless to say, I cannot get this to work with the KL03 board.  I can get the same breakout board to easily work on a competitor's product (and run from the kb/s range of data transfer to the tens of Mb/s range showing that the breakout board can handle a wide range of data transfer speeds).  In fact the bus utilization is an order of magnitude better in the other product.  I am not sure if there is just a significant amount of overhead with the Pex, but the performance on the KL03 is abysmal and that is putting it very kindly.  If all I have the program set up to do is toggle a GPIO pin in a while loop, I can only do it at just under 20kHz.  This should be in the MHz range.  I am not sure if the Pex is just not suited for the KL03 or if there is some other fundamental problem.

I will post some screen shots from my logic analyzer tomorrow.  I am also going to pull out one of my other Freescale dev boards.  I think that I have a KL25 Freedom board around somewhere and I will see if I can get the GPIO to work better as well as the SPI.

Sorry to vent on this, I was just hopeful to be able to use the KL03 for this project as it would have made it unique, but I fear that I will have to move onto another chip/vendor.  That is not to say, Marek, that you have not been very helpful as you have.

0 Kudos

796 Views
aeroengineer1
Contributor II

Marek,

Thanks for pointing out a way to do a simple test.  I was able to do this test, and found that the code I had in place was working.  It seems that the board that I am attached to has a hardware issue on the SS line.  I will debug this tomorrow.

I do have one question for you though, do you happen to know why the SPI_DRV_MasterTransfer() is so very slow between byte transmissions?  If I had a SS pin enabled, The best I can get through the function just blasting bits is about 5kB.  There is a ~.22-.25ms delay before the next bit gets sent out.  If I remove having a SS pin, then I can get that time down to about half.  It just seems like there is very low bus utilization for this function call.  I just started to dig through the source code, but I have not gotten very far yet.

Thanks again for your help.

Adam

0 Kudos

796 Views
aeroengineer1
Contributor II

Marek,

I have confirmed that the pins were both configured as well as the SPI module was also initialized.  I have included a few screen grabs to show that this is the case.  I also am wondering why my configuration screen is different than what you showed in yours.  Even if I set it to advanced, I do not get the same configuration screen.  More of a curiosity than anything else.  I am running the stock KDS 3.0 with integrated Pex and KSDK 1.2.

Also note that I have included a screen capture of the my logic analyzer showing the clock doing what it should, but the data lines being silent.

Adam

5.png

4.png1.png2.png

0 Kudos

796 Views
aeroengineer1
Contributor II

Marek,

I believe that I have properly configured the pins as you suggested.  In the setup, there are only two options for pins that can be chosen, and in each one, I have made a selection.  Also note, the component is set to auto generate the initialization code (that is the setting, though it is greyed out and cannot be unselected).  Though I will be sure to double check tonight when I get back home.

out of curiosity, if that SPI module had not auto initialized, would one expect to see the clock line generating a signal when the SPI_DRV_MasterTransfer() is called?

Also one other piece of information, when debugging, I can see that the correct data is getting passed into the SPI_DRV_MasterTransfer() function, so the comment about initialization may be what I am missing.

Adam

0 Kudos