You are here

SPIM master component trouble with SCLK | Cypress Semiconductor

SPIM master component trouble with SCLK

Summary: 17 Replies, Latest post by Bob Marlowe on 19 Jul 2016 09:44 AM PDT
Verified Answers: 3
Last post
Log in to post new comments.
user_588373's picture
User
16 posts

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

user_588373's picture
User
16 posts

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

 

Regards

Jerson

hli
user_78878863's picture
User
2759 posts

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

user_588373's picture
User
16 posts

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

user_1377889's picture
User
10803 posts

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

user_588373's picture
User
16 posts

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

user_1377889's picture
User
10803 posts

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

 

user_588373's picture
User
16 posts

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

user_1377889's picture
User
10803 posts

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

user_588373's picture
User
16 posts

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

user_1377889's picture
User
10803 posts

"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

Log in to post new comments.