52840 SPIM3 write data size limit

[JohnCC]

Hi,

  I use SDK 17.0.2 and PCA10056 board.

   I use spim3 to connect our LCD panel and I set spim3 frequency is 32MB. I can do init() LCD driver IC very well and draw some picture on our LCD panel.

But I have two questions.

1. I have already config clock GPIO to high drive(NRF_GPIO_PIN_H0H1) and our GPIO is not low frequency GPIO(p0.24). Although we can use normal. But wave pattern of the clock doesn't look very pretty(as below). Is this normal? (Yellow line) 

2. How much data can be sent at one time by DMA? Can I send 240*340*2 data size at a time?

If I cut the frame into thirds it will draw correctly

#define M2_LCD_FRAME_SIZE  240 * 320 * 2    
uint8_t M2_LCD_FrameBuffer[M2_LCD_FRAME_SIZE] = {0};

void spi_lcd_ew_reflash()
{
    nrfx_spim_xfer_desc_t xfer_desc = NRFX_SPIM_XFER_TX(M2_LCD_FrameBuffer,51200);
    
    spi_xfer_done = false;
         
    APP_ERROR_CHECK(nrfx_spim_xfer(&spi, &xfer_desc, 0));
    while (spi_xfer_done == false)
    {;}
    
    xfer_desc.p_tx_buffer = (M2_LCD_FrameBuffer + 51200);
    xfer_desc.tx_length = 51200;
    spi_xfer_done = false;
    
    APP_ERROR_CHECK(nrfx_spim_xfer(&spi, &xfer_desc, 0));
    while (spi_xfer_done == false)
    {;}
    
    xfer_desc.p_tx_buffer = (M2_LCD_FrameBuffer + 102400);
    xfer_desc.tx_length = 51200;
    spi_xfer_done = false;
    
    APP_ERROR_CHECK(nrfx_spim_xfer(&spi, &xfer_desc, 0));
    while (spi_xfer_done == false)
    {;}
}

I threw the whole frame in and it doesn't seem to work

#define M2_LCD_FRAME_SIZE  240 * 320 * 2 
uint8_t M2_LCD_FrameBuffer[M2_LCD_FRAME_SIZE] = {0};

void spi_lcd_ew_reflash()
{
    nrfx_spim_xfer_desc_t xfer_desc = NRFX_SPIM_XFER_TX(M2_LCD_FrameBuffer,240*320*2);
    
    spi_xfer_done = false;
         
    APP_ERROR_CHECK(nrfx_spim_xfer(&spi, &xfer_desc, 0));
    while (spi_xfer_done == false)
    {;}
    
}

typedef struct
{
uint8_t const * p_tx_buffer; ///< Pointer to TX buffer.
size_t tx_length; ///< TX buffer length.
uint8_t * p_rx_buffer; ///< Pointer to RX buffer.
size_t rx_length; ///< RX buffer length.
} nrfx_spim_xfer_desc_t;

So is the length limited to uint16_t? I remember size_t is uint32_t in SDK 17.

Thank you.

 

John.

[hmolesworth]

There is a physical hardware limit of 16-bit on the nRF52840

[JohnCC]

Hi,

   Thank you for your answer. 

About question 1. Our wave pattern of the clock is not good. Is it normal?

[hmolesworth]

Four issues:

1) What is the 'scope probe and 'scope bandwidths? If less than (say) 100MHz the display will be not clean but the signal may be good (more square)

2) How long are the interconnecting leads, more than (say) 25mm (1")? If so display capacitance will be an issue

3) Is "config clock GPIO to high drive(NRF_GPIO_PIN_H0H1) " done after or before the SPI init? I expect you know this must be done after the SPI init.

4) Is the 'scope probe at the source of the SPI clock or the destination? If at the source not good; if at the destination then lead length and display capacitance apply

[JohnCC]

Hi,

1. 100MHz

2. More than 25mm

3. Yes. After SPI init

4. We set GPIO 24 for SPI clock and probe it to monitor.

Thank you.

John.

[hmolesworth]

Perhaps check the 'scope probes are set for x10 and not x1; x1 will produce an output similar to that displayed at 32MHz, Also does probing the SPI clock look different when probed at the pin at or very close to the nRF52 compared with probing at the pin at or very close to the display? If much sharper waveform at the nRF52 (expected) then the lead length may be an issue requiring shortening or adding a single buffer to boost the SPI clock drive strength further.

A 100MHz 'scope might not display jitter at the clock rising and falling edge trigger levels of the display SPI so even when the clock looks clean multiple transitions are "seen" by the display causing data corruption. Either shortening the connections or adding a buffer at the nRF52 helps with that.