SPIM master component trouble with SCLK

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JeFe_286036
Level 3
Level 3

Greetings

   

PSOC Creator version is 3.3 SP2

   

 

   

SPIM component version 2.5

   

 

   

I am trying to use a SPIM  master component on a CY8C3446-AXI099 running @5V.  

   

PSOCMOSI is mapped to port 0.1,  SCLK is mapped to Port 0.3.  Both pins are set to Resistive pull up as the target device operates @3.3V.  Slave can tolerate 5V inputs.

   

SPIM component is set to internal clock @1000kbps.(tried even lesser upto 100kbps)

   

Problem:

   

On scoping, it appears that the SCLK is not toggling enough to clock out the MOSI data.   MOSI shows fast transitions, SCLK shows ramps of very low frequency.

   

Diagnosis

   

Connecting MOSI output to SCLK pin on schematic confirms that the output driver is fine and MOSI signal is being repeated on both pins 0.1 and 0.3 correctly.

   

Interchanging MOSI and SCLK pins so that what was MOSI is now SCLK and vice-versa, the problem of the sleepy SCLK pin shifts to the MOSI pin..

   

This indicates to me that there is some error in either my implementation or the SPIM component.  SCLK does not seem to come out of the pin.

   

Can someone please help me understand what I am doing wrong?  If this has been redressed before, a link to the answer will be helpful.

   

Regards

   

Jerson

0 Likes
1 Solution

Well this is my own designed board connected upto a 3.5" TFT from tinylcd.com  Originally, I had the settings for the port pins @resistive pullup so as to keep the 3.3V tft happy.  However, that was causing the capacitive effects.  Setting the pins to strong seems to have at least got the signals to the TFT.  Still though I am trying to figure out what is preventing the TFT from understanding the SPI signals since I can see some flicker on the TFT with initialization commands being sent.

   

All SPIM signals are clear now though PSOC side is 5V and TFT side is 3.3V.  The manufacturer says the TFT is 5V tolerant on its signals and I know it to be so since I have the same TFT running off a Nuvoton CM0 device.

   

Would anyone know how to change the width of the SPIM-SCLK output?  I suspect there is some timing issue I am seeing here and would like to find the answer.

   

Regards

   

Jerson

View solution in original post

0 Likes
17 Replies
JeFe_286036
Level 3
Level 3

I have made some progress on this after changing some settings.  Kindly ignore the above post for now.

   

 

   

Regards

   

Jerson

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

This seems as if a capacitor is connected to port 0.3. Which board are you using?

0 Likes

Well this is my own designed board connected upto a 3.5" TFT from tinylcd.com  Originally, I had the settings for the port pins @resistive pullup so as to keep the 3.3V tft happy.  However, that was causing the capacitive effects.  Setting the pins to strong seems to have at least got the signals to the TFT.  Still though I am trying to figure out what is preventing the TFT from understanding the SPI signals since I can see some flicker on the TFT with initialization commands being sent.

   

All SPIM signals are clear now though PSOC side is 5V and TFT side is 3.3V.  The manufacturer says the TFT is 5V tolerant on its signals and I know it to be so since I have the same TFT running off a Nuvoton CM0 device.

   

Would anyone know how to change the width of the SPIM-SCLK output?  I suspect there is some timing issue I am seeing here and would like to find the answer.

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Most problems seen so far with SPI were caused by a problem with the ss line which is taken to inactive state as soon as the FIFO gets empty.

   

I would suggest you to try using your own ss pin that you set at begin of a transaction ad reset when the transaction ends using Pin_Write(state);

   

 

   

Bob

JeFe_286036
Level 3
Level 3

Hi Bob

   

sorry for the late response.  I do not get notifications.  Have to check on that.

   

Tried that.  Not much luck.  I seem to have hit some kind of intermittent behaviour and I think it is related directly with the SPI LCD that I am trying to make work.  The same lcd has been checked to be okay on an ARM CM0 setup.  So, it is down to the signal levels 5V CPU, 3.3V LCD and the timing of the signals.  Tried bit-banging just to be sure I can write the LCD albeit slowly; no luck yet.

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can you please post your complete project, so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
JeFe_286036
Level 3
Level 3

Hi Bob

   

First, thanks for being so helpful.  Another set of eyes will sure help.

   

Attached are 2 archives(minimal).  One (archive 2) has the hardware SPIM component being used.  The other archive uses bit-banging to do the SPI.

   

I am suspecting silicon timing variations between builds as the compiler might be routing via different paths on each compile.  The results are not repeatable.  If the display works partially at one time, on a recompile, it will just refuse to work.  I could just be plain wrong on this.

   

Look forward to your comments.  The code is crude as it is a work in progress.

   

BTW: How do I turn on my email notifications?  I seem to miss your posts.

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I do not know what the signals GLCD_RST and GLCD_BL for, but your try to write per program to GLCD_CS will fail as long as the pin is connected to the SPIM component. I see a large potential for ss-errors, so I suggest you to

   

Detach SPIM from CS pin

   

Set CS pin to no hardware connection

   

Maintain CS completely yourself be writing a 0 when starting a transmission and writing a 1 when the transmission has completed. Check that by reading the SPIM_ReadTxStatus() before changing CS.

   

 

   

Bob

0 Likes
JeFe_286036
Level 3
Level 3

Bob

   

Thanks for having a look.  Yes, I am aware of those CS conflicts.  However, I've tried all the permutations possible on that pin including No Hardware Connection.  Somehow, the SPIM_SS connected to GLCD_CS seems to yield at least some hint that the commands are going through to the lcd.

   

BTW: GLCD_RST is LCD reset and BL is backlight  (not of much significance in signalling)

   

"Check that by reading the SPIM_ReadTxStatus() before changing CS."

   

This I got to try.  Maybe, you might have something here.

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

"I've tried all the permutations possible on that pin including No Hardware Connection"

   

No permutations: there are only two solutions: Let SPIM do the job (which sometimes give troubles)

   

or

   

Do the job yourself by driving the pin in software.

   

No mixtures allowed!

   

 

   

Bob

0 Likes
JeFe_286036
Level 3
Level 3

Hi Bob

   

I have been able to pin-point / narrow down to the source of the problem.  The SPIM module seems to have an issue.

   

Bit-banging with CPU running @48MHz works.  This was after changing the Drive Modes of the pins to resistive pullups.

   

Connecting the SPIM module with no conflicts that you mentioned, still does not let the LCD work.  So, it is down to the SPIM module.

   

Is there an alternate way to implement SPI master functionality?  I only need MOSI and CLK outputs.  Shift register looks like a possible candidate, but, I will have to gate the CLK to output only when shifting.

   

Regards

   

Jerson

0 Likes
JeFe_286036
Level 3
Level 3

I'm back once more.  This time with an update.

   

It turns out that the SPIm module has some interactivity with the CPU speed and SPIm clock speed.

   

The following segment of code works as it is shown

   

void SPI_TxData(uint8 dat)
{
    SPIM_WriteTxData(dat);
    while (0==(SPIM_ReadTxStatus() & SPIM_STS_TX_FIFO_EMPTY_SHIFT));
}
Removing the second line seems to confuse the module.  What I noticed is bunching of data packets.  most times I happen to see 16b data instead of 8b.

   

Replacing the 2nd line with CyDelayus(10) seems to work as well.  Only reason for the status check is to do something worthwhile other than just a plain delay.  However, the delay associated with the checking seems to work just fine.

   

Running the module at a lower internal clock speed involves changing this delay amount to get it to work again.

   

What could be the problem??

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I just experienced some issues with a 7-segment 4 digit module with an SPI interface.

   

Cearing the issue were two steps.

   

1st: own SS-line handling

   

2nd: a delay after each transaction (when SS has gone high already) This (as your solution does) allows for the ss-line going high between two transactions. The original ss-line is coupled to fifo empty which will not occur when transmitting several transactions without a wait.

   

 

   

Bob

0 Likes

Hi Bob

   

I am handling the SS line on my own - in code.  Only MOSI and SCLK are handled by the SPIM module.  It seems interesting that a delay is required between 8b transactions else they get combined without delay.  I have a case open with cypress.  Hope to get some insight into this problem.

   

Warm Regards - Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There is nothing magic about the wait: Some slaves require the ss-line to get high after a transaction is made. Because the master does not know what a transaction is (only us designers know that) the handling is made based on the fifo fill level: When the fifo is empty and all data is shifted out, the ss-line is taken high again. When the program does not wait for this when starting a new transaction, the ss-line will not go high in between and the slave might not know of a new transaction.

   

Excerpt from Datasheet:

   

ss – Output
The ss output is hardware controlled. It carries the Slave Select (SS) signal to the slave devices on the bus. The master assigns the slave select output after data has been written into the TX FIFO and keeps it active as long as there are data elements to transmit. It becomes inactive when all data elements have been transmitted from the TX FIFO and shifter register. Note this can happen even in the middle of the transfer if the TX FIFO is not loaded fast enough by CPU or DMA. To overcome this behavior the slave select can be controlled by firmware.

   

 

   

Bob

0 Likes

Hi Bob

   

Well, I understand what you're saying.  But.....

   

I control the SS signal in code.

   

Send byte by byte, so, I expect 8 bit packets going outwards on MOSI

   

Now...If I use the CyDelayUs(10), things work fine.

   

I thought about your explanation regarding the FIFO and it made sense.  So, I used this test after the SPIM_WriteTxData(byte)

   

while (!(SPIM_ReadTXStatus() & SPIM_TX_STS_FIFO_EMPTY));   // wait till FIFO is empty so no concatenation happens

   

This does not help.

   

I have tried other statuses too; like SPI_DONE, BYTE_COMPLETE.  No success.  For now, I will have to live with this anomaly until Cypress decides to fix it.

   

Regards

   

Jerson

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Jerson, try

   

#define Wait(x)

   

void FinishTransaction(void)
{
     while(!(SPIM_ReadTXStatus() & SPIM_STS_SPI_IDLE)) Wait();
     SSLine_Write(1);
}

   

 

   

Bob