This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Potential causes for slowdown after porting from sdk5.2.0/s110 to sdk12.1.0/s130v2.0.1

Hi,

anyone would have any idea (to look at, as to) why the same app running on the same chip/PCB (nrf51822QFAAH rev3) could possibly have slowed down so massively after a port from SDKv5 to SDKv12? Most noticeable are the interaction between CPU and SPI:display and SPI:flash(storage), both being on the same SPI0. Note that when switching back to v5, the speed is fine.

The code basically uses softdevice (for bluetooth, but slowdown is same when BLE is active or not), GPIOTE IRQ (custom), ADC (custom), spi (custom) and 6 timers (app_timer, mininum 1minute resolution), scheduler (app_scheduler).

my sdk_config.h:

#define BLE_ADVERTISING_ENABLED 1
#define BLE_BAS_ENABLED 1
#define BLE_DIS_ENABLED 1
#define BLE_NUS_ENABLED 1
#define APP_SCHEDULER_ENABLED 1
#define APP_TIMER_ENABLED 1
#define CRC16_ENABLED 1
#define FSTORAGE_ENABLED 1 // dont use, there is only a fancy dependency in ble_advertising.c
#define BLE_ADVERTISING_ENABLED 1

The sd is configured with:

#define NRF_CLOCK_LFCLKSRC      { .source        = NRF_CLOCK_LF_SRC_XTAL,            \
                                  .rc_ctiv       = 0,                                \
                                  .rc_temp_ctiv  = 0,                                \
                                  .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM }

unfortunately not much more to tell ... but would really like to hear any hints ...

*EDIT: may it have something with any IRQ/Prioritisations changes from S110>S130

thx

Parents
  • sure (note: I also tried the optimized pre-buffering spi_master.c impl w no success)

    #define spi_tx_rx_8(spi, u8) ({\
     (spi)->TXD = (u8);\
     while ((spi)->EVENTS_READY == 0);\
     (spi)->EVENTS_READY = 0U;\
     ((spi)->RXD);\
    })
    
    #define spi_tx_rx_16(spi, hi, lo) ({ \
     uint16_t rx = (spi_tx_rx_8(spi, hi)) <<  8; \
     (rx | (spi_tx_rx_8(spi, lo) && 0xff)); \
    })
    
    static void __inline__ DISPLAY_SPI_DATA8(const uint8_t u8)
    {
      spi_tx_rx_8(NRF_SPI0, u8);
    }
    
    static void __inline__ DISPLAY_SPI_DATA8PTR(const uint8_t *u8, uint16_t count)
    {
      while (count--)
      {
        spi_tx_rx_8(NRF_SPI0, *u8++);
      }
    }
    
    static void __inline__ DISPLAY_SPI_DATA16COUNT(const uint16_t u16, uint16_t count)
    {
      uint8_t hi = u16 >> 8, lo = u16 & 0xff;
      while (count--)
      {
        spi_tx_rx_16(NRF_SPI0, hi, lo);
      }
    }
    

    display driver (RGB565/2color-bytes per pixel) then calls whatever is appropriate

Reply
  • sure (note: I also tried the optimized pre-buffering spi_master.c impl w no success)

    #define spi_tx_rx_8(spi, u8) ({\
     (spi)->TXD = (u8);\
     while ((spi)->EVENTS_READY == 0);\
     (spi)->EVENTS_READY = 0U;\
     ((spi)->RXD);\
    })
    
    #define spi_tx_rx_16(spi, hi, lo) ({ \
     uint16_t rx = (spi_tx_rx_8(spi, hi)) <<  8; \
     (rx | (spi_tx_rx_8(spi, lo) && 0xff)); \
    })
    
    static void __inline__ DISPLAY_SPI_DATA8(const uint8_t u8)
    {
      spi_tx_rx_8(NRF_SPI0, u8);
    }
    
    static void __inline__ DISPLAY_SPI_DATA8PTR(const uint8_t *u8, uint16_t count)
    {
      while (count--)
      {
        spi_tx_rx_8(NRF_SPI0, *u8++);
      }
    }
    
    static void __inline__ DISPLAY_SPI_DATA16COUNT(const uint16_t u16, uint16_t count)
    {
      uint8_t hi = u16 >> 8, lo = u16 & 0xff;
      while (count--)
      {
        spi_tx_rx_16(NRF_SPI0, hi, lo);
      }
    }
    

    display driver (RGB565/2color-bytes per pixel) then calls whatever is appropriate

Children
No Data
Related