Any relation between SPIM, PPI, TIMER and DFU bootloader?

RE: Any relation between SPIM, PPI, TIMER and DFU bootloader?

Hung Bui — Thu, 01 Sep 2016 10:48:43 GMT

If you don't plan to keep the SPI task when you are in bootloader mode. I don't see the point of keeping the ppi channel when you branch to the bootloader.

I still keep my concern that if you keep the peripheral running when you branch to the bootloader, especially when you forward the vector table to the bootloader's one you will have trouble when the interrupt comes.

It's recommended to stop all the peripherals you use in the application before you branch to the bootloader.

If you want to dig deeper, I would suggest to run the bootloader project in debug mode and wait for the application to branch to the bootloader and debug from there (you would need to remove optimization in the bootloader to debug)

RE: Any relation between SPIM, PPI, TIMER and DFU bootloader?

bvuong87 — Wed, 31 Aug 2016 17:38:24 GMT

@hungbui: Apologies, my description may have been a little unclear.

I'm not trying to continue running the SPI task while in bootloader mode. The SPI task is setup to run in the main application, connected to the timer event using:

    err_code = nrf_drv_ppi_channel_alloc(&m_ppi_channel);
   APP_ERROR_CHECK(err_code);

   err_code = nrf_drv_ppi_channel_assign(m_ppi_channel, timer_compare_event_addr, spi_transfer_event_addr);
   APP_ERROR_CHECK(err_code);

   err_code = nrf_drv_ppi_channel_enable(m_ppi_channel);
   APP_ERROR_CHECK(err_code);

Inside of the main application, the SPI task works as expected. However, the problem I'm seeing is when entering DFU bootloader mode through the NRF Connect phone app, the log shows the application restarts and entering into bootloader mode, however NRF connect is unable to reconnect to the device to continue the DFU process and send the new application OTA unless I disable the ppi channel in the function which starts the bootloader from the main application.

#include "nrf_drv_ppi.h"

void bootloader_util_app_start(uint32_t start_addr)
{
    nrf_drv_ppi_channel_free(m_ppi_channel);  // m_ppi_channel is the "short" between timer event and SPIM task
    bootloader_util_reset(start_addr);
}

I'm assuming it's some sort of hard fault, or app_error_check() (although haven't completely verified) after it enters the bootloader since when this occurs, the nrf52 doesn't advertise (as either DfuTarg, or the application name) and requires a power cycle. Note - that the DFU OTA application update also worked with the identical bootloader, before adding the PPI implementation

Is this to be expected? I wouldn't think so since I have some another PPI channel allocated and enabled between the same timer event and a GPIOTE task which controls a CS pin which doesn't need to be disabled

RE: Any relation between SPIM, PPI, TIMER and DFU bootloader?

Hung Bui — Wed, 31 Aug 2016 12:53:02 GMT

@bvuong87: please correct me if I'm wrong. You want to continue doing the SPI task when you are in bootloader mode by using PPI and let the timer and SPI running without CPU involvement ? But you have hardfault/assert when you enter bootloader ?

If you call nrf_drv_ppi_channel_free() you don't have any issue continue with the bootloader ?

You would need to make sure all the interrupt handler is implemented or you disable the interrupt flag the peripherals you use but don't handle them in the bootloader code.

The nrf_driver actually enable interrupt flag for the timer and the SPI. I would suggest to use the TIMER and SPI directly so you know for sure what you enable.