This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issue with updating nRF52832 over USART

 I am using an STM32L4 chip that sends an update to the nRF52832 on a ublox module over USART. I assume the nordic chip is in the bootloader during the update.

We get a UART error: 4 and when we observe the UART lines we see that on the TX line of the nRF the stop bit is not present. I assume the nRF does not pull the line high properly after transmitting a frame. (we do not use pull-up resistors on the USART lines on STM32L4 side)

When trying to update with an OTA the device updates but then falls back into the bootloader at startup making me assume the problem is with the bootloader.

 

I am wondering if there is such documented cases of bootloader errors or if the missing stop bit could point to another issue with my HW/SW?

Thank you for any hint!

Bad behavior with missing stop bit:

Good behavior with stop bit present:

Bad behavior with 

  • blue: CTS

  • red: RTS

  • green: UART RX

  • yellow: UART TX

Parents
  • We get a UART error: 4 and when we observe the UART lines we see that on the TX line of the nRF the stop bit is not present. I assume the nRF does not pull the line high properly after transmitting a frame. (we do not use pull-up resistors on the USART lines on STM32L4 side)

    This UART error:4, is it on the nRF end or the STM end? UART on nrf52832 is quite mature peripheral and I do not suspect that there is an hardware issue with it.

    There probably is a configuration issue with the pullup on the nRF side or the STM side.

    Can you show some code snippets on how you are configuring the pins on the UART on nRF side?.

  • Ok yes you are right, we do not use the LFCLK as source.

    I think we should use nrf_drv_clock_hfclk_request when there is no softdevice (only UART updates).

    However, in my case we also allow Bluetooth and the Softdevice to enable OTA updates. Therefore sd_clock_hfclk_request() has to be used.

    What I currently do is this:

            // init SD
            ret_val = nrf_dfu_init(dfu_observer);
    
            nrf_delay_ms(500);
    		sd_clock_hfclk_request();
    
    		//delay for startup of crystal: Typical startup times is 200-400 ms for low frequencies and 200 µs to 400 µs in the high frequency domain
    		nrf_delay_ms(500);
    
    		uint32_t is_running = 0;
    		uint32_t * p_is_running = &is_running;
    
    		if(sd_clock_hfclk_is_running(p_is_running)){
    		   //send debug message if the HF clock is running
    		   NRF_LOG_DEBUG("sd_clock_hfclk_is_running");
    		}
    
    
            loop_forever(); // This function will never return.
            NRF_LOG_ERROR("Unreachable");

  • The code looks ok except the delays seems to be random. Better would be do this

        err_code = sd_clock_hfclk_request();
        APP_ERROR_CHECK(err_code);
    
        uint32_t hfclk_is_running = 0;
    
        while (!hfclk_is_running)
        {
            APP_ERROR_CHECK(sd_clock_hfclk_is_running(&hfclk_is_running) );
        }

    I do not see anything else which points as obviously wrong apart from not knowing the accuracy of your XTAL HFCLK. 

Reply
  • The code looks ok except the delays seems to be random. Better would be do this

        err_code = sd_clock_hfclk_request();
        APP_ERROR_CHECK(err_code);
    
        uint32_t hfclk_is_running = 0;
    
        while (!hfclk_is_running)
        {
            APP_ERROR_CHECK(sd_clock_hfclk_is_running(&hfclk_is_running) );
        }

    I do not see anything else which points as obviously wrong apart from not knowing the accuracy of your XTAL HFCLK. 

Children
No Data
Related