PmodCLS - missing character on SPI

[krzysiekch]

Hi,

I'm trying to use my PmodCLS (rev. E) with an STM32F723E-DISCO board. I connected it to the SPI port (J1 connector) and configured the SPI with CPOL=1 CPHA=0. I configured the module using the following commands:

  write("\x1b[j", 3);
  write("\x1b[0h", 4);
  write("\x1b[0c", 4);
  write("\x1b[0;0H", 6);

Then I'm sending some ASCII string. The problem is that the last character does not appear on the display. I investigated it for some time and found out that it concerns also the commands. It looks like the last character from the previous transaction is received by the Pmod at the beginning of the next transaction. For example, if I send "ABC" I can see only "AB" on the LCD. But when I send "DEF" after that I can see "ABCDE".

I checked the waveforms on the scope but all the signals look fine and all the data is transmitted from the STM32 microcontroller's SPI. To make sure that it is not the SPI configuration I also checked other SPI modes but changing CPHA to 1 has the same effect, and changing CPOL to 0 causes the module to display trash because some bits from the beginning of each transaction are lost.

I suspect that it is some problem with my configuration but I have no more ideas what can I change to make it work fine.

 

Thanks for any help,

Chris

[JColvin]

Hello @krzysiekch,

I agree that this is also likely an issue with the configuration, but I am not sure what it is at the moment. I hope to be able to get back to you with some more information on this or things to try tomorrow.

Thank you,
JColvin

[krzysiekch]

Hi @JColvin

Thank you for the reply. I still can't solve the issue but maybe you could confirm what should be the SPI mode for the PmodCLS. I can't find any information about this i the docummentation, but I think it may be the good point to start looking for the reason of my problem. I set the SPI clock to the lowest possible frequency for my current system clock. The scope confirms that it is about 230kHz. I tried also 460 kHz, but the behaviour is exactly the same.

I have also found out that in the SPI mode 0, the string is displayed correctly after power on, but after CPU reset using the reset button, there is probably a shift in the received serial data. After 8 resets the correct string is visible again. It looks like some data is sent during/after reset which remains in the SPI buffer of the PmodCLS. When I try to send the string or configuration, the data is just added to this buffer without clearing it. The chip select is active (in low state) for each byte separatelly.

 

Thank you,

Chris

 

[D@n]

@krzysiekch,

How are you controlling the SPI CS_n pin?  That should help you frame your data properly.

Dan

[krzysiekch]

3 minutes ago, D@n said:

How are you controlling the SPI CS_n pin?  That should help you frame your data properly.

Hi @D@n,

When I have the SPI configured in mode 0, the CS is controlled by hardware. In mode 2, the CS in controlled by software as normal GPIO. It is reset to low state before the first edge of the SPI clock and set to high after each byte transmission. I also try to keep it low for multiple bytes transaction, but with the same result.

Chris

[D@n]

@krzysiekch,

Try setting it high as part of your initialization sequence, and only lowering it to send a single character.  This is how I've interacted with the PModCLS quite successfully.

Dan

[krzysiekch]

@D@n,@JColvin,

I tried once again with the logic analyzer and recorded the signal of the first transaction ("\x1b[j"), which should clear the display. Unfortunately, it clears the display but only after power on and after each 8th CPU reset. In other cases, it causes some characters to appear which correspond to the shifted data. Strange thing is that the CS signal remains high during the whole CPU reset, so there should be none additional bits sent to the controller. The clock frequency is 430kHz.

In this configuration, the CS pin is controlled by the hardware, as well as the remaining signals.

Chris

[D@n]

@krzysiekch,

Why is your clock idling low?  Shouldn't it idle high in CPOL=1 mode any time the select line is high as well?  I also thought the clock had to drop after the select line did.  I'm not sure if this makes a differences with the CLS or not ... it's just the way I've used it successfully.

Dan

[krzysiekch]

@D@n,

This configuration is Mode 0, so CPHA = 0 and CPOL = 0. That's why the clock drops low before the CS (data is sent on the rising edge). The CS is high all the time (except data transmission as shown in the screenshot).

Maybe the mode 0 is wrong - should the clock phase be 1 (idle in the high state)? What SPI configuration did work for you?

Chris

[D@n]

@krzysiekch,

Looks like I used CPOL=1, CPHA=0 -- assuming I've got the terminology right.  Be aware, though, I always "bit-banged" the port.  You can see my software here, if you'd like.  Perhaps that'd help.  (In the exaple software, the GPOSETV() macro sets a pin high, whereas GPOCLRV() sets the pin low.)

Dan

[krzysiekch]

@D@n, @JColvin

Thank you for your help - the problem is solved. Of course, it was my fault - but there was no problem with the SPI configuration. The reason was the Jumper 1 on the PmodCLS board - I did not connect the CS signal from my microcontroller. Without the Jumper, the CS is low all the time, so the LCD controller latches every clock edge - including the GPIO initialization state changes.

At least I learned to check the schematics more carefully.

 

Thank you again for your help,

Chris