• State Not Answered
  • Replies 6 replies
  • Subscribers 65 subscribers
  • Views 123 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 330154
Options

nRF52840 BLE causing display glitch on GC9A01 using SPIM

wyatt_tritium

We have a product based on the nRF52840 which uses the GC9A01 display driven using SPI on battery power. The device also functions as a Bluetooth connectable so it is normally advertising data at a 1 second interval. If the display is left on for several hours while BLE is enabled, the display will randomly become glitched and stays this way until reset. It appears that the BLE is somehow interfering with SPI and causing corrupt data eventually. We are fairly confident that the issue is not hardware related, as we have eliminated noise using stable power supplies and impedance matching the SPI lines.

Is it possible that the nRF is low on resources and corrupting the SPI data or display buffer when using BLE?

The pin-out for the display is as follows.

  • DC - P0.06
  • CS - P0.08
  • RESET - P0.11
  • SDA - P0.12
  • SCL - P1.09

We are using nRF Connect SDK v2.5.1.

Parents
  • 0

    Hi,

    There is no known issue like this. 

    How much resources your program is using? If there is an overflow then the compilation would tell you about that.

    If there is run time issue then you should debug and locate where the problem is occurring.

    /br

    Naeem

  • 0 in reply to Naeem Maroof

    Here is the build output. There is no overflow.

    Memory region         Used Size  Region Size  %age Used
               FLASH:      953705 B         1 MB     90.95%
                 RAM:      145660 B       256 KB     55.56%
            IDT_LIST:          0 GB         2 KB      0.00%

    The issue occurs during runtime, but I do not see how to debug it because the issue occurs randomly after several hours to several days.

  • 0 in reply to wyatt_tritium

    I am not sure what could be the issue.

    Are there any logs etc to see if there is any fault reported by the mcu?

    Could there be issues with the display itself? like known issues etc?

  • 0 in reply to wyatt_tritium

    Simple test: Ensure the RAM areas used by the BLE RADIO and the SPIM are in separate RAM AHB bus masters to see if that improves the performance. We know that SPIM data corruption can occur if the bus master is stalled while attempting to retrieve the next byte from RAM via DMA which can lead to the display commend/data sequence being incorrect. The RADIO has higher priority than the SPIM and will cause a SPIM DMA bus stall on conflict, which may or may not affect the data stream; worse at higher SPIM clock speeds. Here a some brief notes copied from my code (nRF52833, similar to nRF52840); ensuring separate AHB RAM areas is trivial in SDK, not so easy in nRFConnect; please post any results if you get this test to work. The .map file will show whether the RAM areas are indeed separate.

    // nRF52833 Bus Masters
// ====================
// Each bus master is connected to all the slave devices using an interconnection matrix. The bus masters are
// assigned priorities, which are used to resolve access when two (or more) bus masters request access to
// the same slave device. When that occurs, the following rules apply:
// - If two (or more) bus masters request access to the same slave device, the master with the highest
// priority is granted the access first.
// - Bus masters with lower priority are stalled until the higher priority master has completed its transaction.
// To avoid AHB bus contention when using multiple bus masters, follow these guidelines:
// - Avoid situations where more than one bus master is accessing the same slave.
// - If more than one bus master is accessing the same slave, make sure that the bus bandwidth is not exhausted.
// Bus Slaves (RAM):
//           Name  AdrSpace    StartAdr    EndAdr      AccType
// Memory =  RAM0  Memory      0x20000000  0x20001FFF  RW
// Memory =  RAM1  Memory      0x20002000  0x20003FFF  RW
// Memory =  RAM2  Memory      0x20004000  0x20005FFF  RW
// Memory =  RAM3  Memory      0x20006000  0x20007FFF  RW
// Memory =  RAM4  Memory      0x20008000  0x20009FFF  RW
// Memory =  RAM5  Memory      0x2000A000  0x2000BFFF  RW
// Memory =  RAM6  Memory      0x2000C000  0x2000DFFF  RW
// Memory =  RAM7  Memory      0x2000E000  0x2000FFFF  RW
// Memory =  RAM8  Memory      0x20010000  0x2001FFFF  RW

Reply
  • 0 in reply to wyatt_tritium

    Simple test: Ensure the RAM areas used by the BLE RADIO and the SPIM are in separate RAM AHB bus masters to see if that improves the performance. We know that SPIM data corruption can occur if the bus master is stalled while attempting to retrieve the next byte from RAM via DMA which can lead to the display commend/data sequence being incorrect. The RADIO has higher priority than the SPIM and will cause a SPIM DMA bus stall on conflict, which may or may not affect the data stream; worse at higher SPIM clock speeds. Here a some brief notes copied from my code (nRF52833, similar to nRF52840); ensuring separate AHB RAM areas is trivial in SDK, not so easy in nRFConnect; please post any results if you get this test to work. The .map file will show whether the RAM areas are indeed separate.

    // nRF52833 Bus Masters
// ====================
// Each bus master is connected to all the slave devices using an interconnection matrix. The bus masters are
// assigned priorities, which are used to resolve access when two (or more) bus masters request access to
// the same slave device. When that occurs, the following rules apply:
// - If two (or more) bus masters request access to the same slave device, the master with the highest
// priority is granted the access first.
// - Bus masters with lower priority are stalled until the higher priority master has completed its transaction.
// To avoid AHB bus contention when using multiple bus masters, follow these guidelines:
// - Avoid situations where more than one bus master is accessing the same slave.
// - If more than one bus master is accessing the same slave, make sure that the bus bandwidth is not exhausted.
// Bus Slaves (RAM):
//           Name  AdrSpace    StartAdr    EndAdr      AccType
// Memory =  RAM0  Memory      0x20000000  0x20001FFF  RW
// Memory =  RAM1  Memory      0x20002000  0x20003FFF  RW
// Memory =  RAM2  Memory      0x20004000  0x20005FFF  RW
// Memory =  RAM3  Memory      0x20006000  0x20007FFF  RW
// Memory =  RAM4  Memory      0x20008000  0x20009FFF  RW
// Memory =  RAM5  Memory      0x2000A000  0x2000BFFF  RW
// Memory =  RAM6  Memory      0x2000C000  0x2000DFFF  RW
// Memory =  RAM7  Memory      0x2000E000  0x2000FFFF  RW
// Memory =  RAM8  Memory      0x20010000  0x2001FFFF  RW

Children
Related