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

timer seems to stop

The hardware is a custom board with a Rigado BMD300 module (which uses the nRF52832).  I am using Softdevice S132.

My code base started as the ble_app_uart peripheral example.  To this I am trying to add SPI code to communicate with multiple SPI-to-UART bridges on SPI0 and SPI1 although I do not believe the problem is with the SPI code.

After sending a message to a SPI slave my code calls a delay_ms() routine and waits for the SPI to finish.

      // Set LCR to 0x80
      tx_buf[0] = SC16IS7X0_WRITE | (SC16IS7X0_LCR << SC16IS7X0_ADDR_SHIFT);	// R/W and address
      tx_buf[1] = 0x80;			// value
      *busy_flag = SPI_TX_IN_PROGRESS;
      
      nrf_drv_spi_transfer( spi_instance, tx_buf, 2, NULL, 0 );
      while( *busy_flag != SPI_AVAILABLE )
      {
	 delay_ms( 2 );
      }

void delay_ms( uint32_t count)
{
   uint32_t			end;
   
   if( timestamp != 0 )
   {
      end = count + timestamp;
      
      while( timestamp < end )
      {
	   //NRF_LOG_PROCESS();	// may as well do something useful
	 asm("nop");
      }
   }
   
   return;
}  // end of delay()

The timestamp variable is updated in my timer callback.  I put a debug statement to toggle an LED n the callback and verified it was both running and running at the expected rate (1 ms).

The busy_flag is updated in the SPI event handler.

The code often gets stuck waiting to the delay_ms() to complete.  The only way I can see that happening is for the app_timer() library to stop running under some circumstance.

When I put a breakpoint (I am using IAR's EWARM and a Segger JLINK) in the timestamp timer's handler routine after a few seconds of the application hanging, the call stack looks like the following:

Stepping through the code (and checking the disassembly) shows the expected result: the global timestamp variable is incremented by one.

I would guess that the timer stopped running except that the breakpoint in the timer service routine was encountered and stopped the debugger.

I realize there is an overflow possibility if the timestamp is close to max but since it starts at zero there shouldn't be a problem.

Any suggestions on what to look at or how to debug this?  Using the debugger breaks the code - I eventually hit a NRF_BREAKPOINT_COND in the app_error_fault_handler().  I am using the Segger RTT Viewer to see printf()'s sprinkled through the code but I'm not getting anywhere fast.

Parents Reply Children
No Data
Related