nrf_delay_ms clock issues

[Taylor]

I'm using nrf_delay_ms in main on "ble_app_beacon", but the delay time is much longer than I set.

I have set 2000ms delay to log, but it seems 4s or longer than I set.

int main(void)
{
	uint32_t num=0;
    // Initialize.
    log_init();
    timers_init();
    leds_init();
    power_management_init();
    ble_stack_init();
    advertising_init();

    // Start execution.
    NRF_LOG_INFO("Beacon example started.");
		NRF_LOG_FLUSH();
    advertising_start();

    // Enter main loop.
    for (;; )
    {
			nrf_delay_ms(2000);
			NRF_LOG_INFO("beacon test %d",num);
			NRF_LOG_FLUSH();
			num++;
        idle_state_handle();
    }
}

[Vidar Berg]

Hello,

I see you tagged the question with 'nRF52810', does that mean you are you running this code on an actual nRF52810 SoC? In that case, please make sure you don't have the NRFX_COREDEP_DELAY_US_LOOP_CYCLES flag defined in your project settings (see Transferring the project to nRF52810 hardware for details). This flag is used by the nrf_delay implementation to determine how many NOP instructions it needs to run for a given delay.

[Taylor]

Hi Vidar,

I have tested after deleted the NRFX_COREDEP_DELAY_US_LOOP_CYCLES  and DEVELOP_IN_NRF52832, the clock seems worked normally, but there is another problem.

In my code, LED will change the status for every 2 seconds, but the LED just changed two times and then never change.

int main(void)
{
	  uint8_t  rcv = 0;
		const char * txbuff = "AnyTek";
		uint8_t rcvbuff[ 32 ] = { 0 };
    // Initialize.
		log_init();
    timers_init();
//    leds_init();
    power_management_init();
    ble_stack_init();
    advertising_init();

    // Start execution.
    NRF_LOG_INFO("Beacon example started.");
		NRF_LOG_FLUSH();
    advertising_start();
		platform_gpio_initialize();
		platform_gpio_int_initialize();
		twi_master_init();
		m_sensor_work_init();
//		m_CC1101_Init(0xAA);
//		CC1101_Init();
//		NRF_LOG_FLUSH();
    // Enter main loop.
    for (;; )
    {
//			if(GSENSOR_Get_Transient_Detection_Flag() == true)
//			{
//				nrf_gpio_pin_toggle(GREEN_PIN);
//				nrf_delay_ms(200);
//			}
//			NRF_LOG_INFO("Test");
//					CC1101_Tx_Packet((uint8_t *)txbuff,6,ADDRESS_CHECK);
//			NRF_LOG_FLUSH();
//			CC1101_Tx_Packet((uint8_t *)txbuff,6,ADDRESS_CHECK);
//				CC1101_Clear_RxBuffer( );
//				CC1101_Set_Mode( RX_MODE );
//				rcv = CC1101_Rx_Packet( rcvbuff );
				nrf_delay_ms(2000);
				nrf_gpio_pin_toggle(GREEN_PIN);
//			NRF_LOG_FLUSH();
      idle_state_handle();
    }
}

[Taylor]

Hi,

I have a question of HW driver(TWI master)

nrf_drv_twi_rx(&m_twi, LM75B_ADDR, &m_sample, sizeof(m_sample))

And there is only one address which is device address, but I want to read the value of some registers, what should I do?

[Vidar Berg]

Hi,

Unless you are using a "preset pointer", you need to issue a write command to the sensor first telling it what you want to read. nrf_drv_twi_rx() will just set up the TWIM in receive mode and wait until the sensor replies back.

I found these from the datasheet:

https://www.nxp.com/docs/en/data-sheet/LM75B.pdf

You can use the NRF_DRV_TWI_XFER_TXRX (see Repeated transfers) helper macro to set up a complete TWI TX RX transaction.

[Taylor]

Thanks！I have read register value successful.

Vidar Berg said:

Why don't you want HW driver instead (TWI master) ?

I'm sorry for forgetting reply you.In our application, we need both of twi and spi peripherals.

Could I use HW driver(TWI master and SPIM master) at the same time in nRF52810?

Both TWI or SPIM HW driver would occur more current?

[Vidar Berg]

Excellent! Yes, you can use TWIM0 and SPIM0 at the same time as they do not share the same peripheral ID:

Instantiation Peripherals with shared ID

[Taylor]

Thanks！

I have another question about HW driver(SPIM).

For example, I want to send register address to recieve some data.

APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &addr_burst, 1, pReadBuff, ReadSize))

I thought the 'pReadBuff' is correct,but pReadBuff[0] is 0x00 and the data starting from pReadBuff[1] will be wanted data.

So I have to modify like this.

APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &addr_burst, 1, pReadBuff-1, ReadSize+1))

[Vidar Berg]

Hi,

Do you have a logic analyzer or oscilloscope you can use to prope the bus lines? I'm wondering if the slave is returning 0x00 on the first read?

Taylor said:

pReadBuff-1

I would not recommend this. It will cause the SPIM to write outside of the pReadBuff buffer.