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.
