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

spi fails after removing print statements

So i am utilizing SPI and i got it to work, however for some absurd reason after removing the segger_print statement below from before the while loop the spi would stop functioning. otherwise it works perfectly fine. Any idea why a print statement would cause this? do i need to add a delay? Although i would expect the while loop to handle any delay necessary.

uint32_t LCD_SPI_Write_Command (uint8_t command)
{
	spi_lcd_xfer_done = false;
	LCD_CSX_LOW(); //	set CSX to low to activate LCD listening
	LCD_DCX_LOW(); // indicate command
	uint32_t err_code = nrf_drv_spi_transfer(&m_spi_LCD, &command, 1, NULL, 0);
	if (err_code != NRF_SUCCESS) {
		SEGGER_RTT_printf(0, "[ERROR] on command transfer :%d \n", err_code);
	}
		SEGGER_RTT_printf(0,"Im writing a command! \n");

	while (!spi_lcd_xfer_done)
	  {
	  }
	return err_code;
}
Parents
  • thanks kl-cruz it actually worked. i still dont fully understand why the elimination of a comment would prevent it from working and simply adding the keyword volatile would permit it to work again.

    as for your other recommendation, i didnt fully understand it. I dont have a thread or OS. simply one main method. but i guess what you are recommending is to do something similar to this right?

    if (spi_lcd_xfer_done ==true) {
          nrf_drv_spi_transfer();
    }
    

    so it wont send data unless transfer is done and that way it wont wait at while loop right?

  • " i still dont fully understand why the elimination of a comment would prevent it from working and simply adding the keyword volatile would permit it to work again. " Well, compiler is an interesting thing. Trying to simplify and speed up code as much as it can. Variable without volatile keyword will be probably stored locally and in addition if You modify twice this variable then it can be optimized to one, only last statement (so it is important to use volatile in hardware and peripherall contexts). I mean that compiler fetch this variable from RAM memory and will store it in CPU register within your function context. Variable in interrupt handler will work the same way. Compiler probably load value from RAM memory to register and change it locally within irq context. It is part of optimization. Look, in most cases You uses variable in within one context.

Reply
  • " i still dont fully understand why the elimination of a comment would prevent it from working and simply adding the keyword volatile would permit it to work again. " Well, compiler is an interesting thing. Trying to simplify and speed up code as much as it can. Variable without volatile keyword will be probably stored locally and in addition if You modify twice this variable then it can be optimized to one, only last statement (so it is important to use volatile in hardware and peripherall contexts). I mean that compiler fetch this variable from RAM memory and will store it in CPU register within your function context. Variable in interrupt handler will work the same way. Compiler probably load value from RAM memory to register and change it locally within irq context. It is part of optimization. Look, in most cases You uses variable in within one context.

Children
No Data
Related