- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have made some progress on this after changing some settings. Kindly ignore the above post for now.
Regards
Jerson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems as if a capacitor is connected to port 0.3. Which board are you using?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jerson, try
#define Wait(x)
void FinishTransaction(void)
{
while(!(SPIM_ReadTXStatus() & SPIM_STS_SPI_IDLE)) Wait();
SSLine_Write(1);
}
Bob