0

I am using Waveshare 1.54" ePaper Module. Using SPI peripheral:

  • CPU freq is 16Mhz
  • SPI Prescaler DIV by 8
  • MSB FIRST
  • CPOL=0, CPHA=1

The Display does not response but it respond with TI CC1310 properly. The problem with SPI is after transmitting byte it does not go to ideal high state.

I have checked with logic analyser. enter image description here enter image description here

The SPI is initialised thus:

/****************** Initializing The SPI Peripheral ******************/

void SPI_setup(void)
{
    CLK_PeripheralClockConfig(CLK_PERIPHERAL_SPI, ENABLE);  //Enable SPI Peripheral Clock
    //Set the MOSI, MISO and SCk at high Level.
    //GPIO_ExternalPullUpConfig(GPIOC, (GPIO_Pin_TypeDef)(GPIO_PIN_6),ENABLE);
    SPI_DeInit();
    SPI_Init(SPI_FIRSTBIT_MSB,                    //Send MSB First
             SPI_BAUDRATEPRESCALER_8,             //Fosc/16 = 1MHz
             SPI_MODE_MASTER,
             SPI_CLOCKPOLARITY_LOW,               //IDEAL Clock Polarity is LOW
             SPI_CLOCKPHASE_2EDGE,                //The first clock transition is the first data capture edge
             SPI_DATADIRECTION_2LINES_FULLDUPLEX, //Only TX is Enable 
             SPI_NSS_SOFT,
             0x00);
    SPI_Cmd(ENABLE);
}
Lundin
  • 195,001
  • 40
  • 254
  • 396
Naman Shandilya
  • 21
  • 2
  • What do those "magic" functions do? – 0___________ Jan 06 '21 at 21:26
  • I removed the zoom'ed out trace previously as irrelevant, but now it is apparent that it is the busy signal that concerns you (even though your SPI mode was incorrect), I have added it back in. I would have assumed that given the SPI mode correction however the BUSY would have become valid. Probably better to start a new question with the correct SPI mode if it is still not working since you then clearly have other problems. – Clifford Jan 08 '21 at 13:56
  • I note that the Waveshare WiKi states _"BUSY Busy state output pin (Low for busy)"_ while the [User Manual](https://www.waveshare.com/w/upload/7/7f/1.54inch_e-paper_module_user_manual_en.pdf) says _"BUSY ：Busy（High active"_. Good luck with that! This inconsistency is noted at https://github.com/mcauser/micropython-waveshare-epaper/issues/2. The example code provided agreed with the user manual - i.e. BUSY = HIGH. Note the pin state refers to the busy state of the display, not the SPI interface. Have you configured the GPIO correctly? I appreciate that I deleted that code as irrelevant! – Clifford Jan 08 '21 at 14:54
  • ... Looking at the original code BUSY was configured `GPIO_MODE_IN_FL_NO_IT`. – Clifford Jan 08 '21 at 15:04
  • The documentatuion fo rteh part is terrible, only showing how to use it with libraries - where are you getting your information on how to drive this from? What makes you think that the BUSY state should change when you send that sequence? The documentation makes no mention of the purpose to behaviour of that pin. What are you expecting to happen, what actually happens? – Clifford Jan 11 '21 at 18:07

1 Answers1

0

This is pretty much the same problem you had at Issue in interfacing SPI e-ink display with PIC 18F46K22 only on a different processor. Worth noting that CPHA on STM8 has the opposite sense to CPE on PIC18 which may be the cause of your error. That is to say that CPHA=1 on the STM8 has the same effect as CKE=0 on the PIC18. You really have to look at the timing diagrams for each part carefully.

From https://www.waveshare.com/wiki/1.54inch_e-Paper_Module: enter image description here

Compare with the STM8 reference manual: enter image description here

Clearly you need one of:

  • CPHA=1 / CPOL=1 (SPI_CLOCKPOLARITY_HIGH / SPI_CLOCKPHASE_2EDGE) or
  • CPHA=0 / CPOL=0 (SPI_CLOCKPOLARITY_LOW / SPI_CLOCKPHASE_1EDGE)

If it is the SCLK that you want to be normally-high, then you need the first option - although I fail to see why that is "ideal", the Waveshare diagram clearly indicates that either is acceptable.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks Clifford for response, I have already checked both the conditions you have mentioned in PIC and STM8. But it does not work. – Naman Shandilya Jan 08 '21 at 07:11
  • The problem i think is in MOSI signal. When i compare the waveform with TI one i found the busy pin react only at the time of rest and remains ideal all the time when i send initializing and clearing data to the display. – Naman Shandilya Jan 08 '21 at 07:14
  • @NamanShandilya your question does not mention concern over the busy pin. It simply states that _" it does not go to ideal high state"_ without specifying what "it" is. It is also not clear what you mean by "ideal". I can only address the problems I see, and this was one. Fix that, get a new logic analyser trace, and post a new question. BUSY is not an SPI signal, to determin what that should do would require me to further look at the documentation - you could do that. – Clifford Jan 08 '21 at 08:06
  • ok I will repost with proper description of problem what i am facing. – Naman Shandilya Jan 08 '21 at 13:46
  • @NamanShandilya : Is it working on your PIC18 implementation? I have to assume not since you have not accepted that answer either. It would be useful to know. – Clifford Jan 08 '21 at 13:48
  • No it won't work on PIC18 that's why i switched to STM8. – Naman Shandilya Jan 11 '21 at 12:14
  • @NamanShandilya Yet you made the same error on STM8. I suggest you stick to one platform and resolve the issue before moving to a different platform. It is not the microcontroller that is your problem here. Having corrected the phase/polarity, (which is certainly _one_ reason it would not work, what you then have is a _different_ problem, and you might post a new question with a new timing trace. To switch platforms, and get the phase/polarity wrong _again_ is a backward step. – Clifford Jan 11 '21 at 17:55