Does SPI instance 3 (extended) support EASY_DMA?

Hi!

I have a bootloader using SPI 3 for a bootloader LCD animation. 
Unless I attach an RTT console, the animation causes my DFU to fail 100% of the time. 
It is making me wonder if SPI3 supports EASY_DMA. It's not obvious from the sdk_config.h 

If I disable the animation, DFU passes 100% of the time, so I'm thinking there might not be DMA on this SPI instance. 

question 2 - is there any documentation on known issues with DFU and RTT? 

thanks.

Parents
  • Hi,

    It is using DMA. SPIM3 is actually not available without easy DMA. But it is interesting that it is not failing when you are viewing RTT logs which requires the chip to be in debug interface mode. This should usually not have any noticeable impact on the executon How is the DFU failing, do you see any error messages while uploading the FW? And does the device reboot and go back to running the old application after it fails?

    Best regards,

    Vidar

  • Thanks Vidar. 

    Another data point. 
    The nordic DFU IOS client is sending packets faster ~5.5 kbps, and fails 100% of the time with animation enabled. 
    The nordic DFU android client is sending packets around ~3 kbps, and passes 100% of the time with animation enabled.

    The failure mode on IOS is that it'll get to about 2-3% and it just stops. 
    The RTT console is dropping data, so I do not see the failure indication, way too much printing to that console unfortunately. I was testing this without an application, so it just reboots into the bootloader. 

  • Thanks for the additional information. It sounds like the issue might be that your bootloader cannot keep up with the higher transfer rate from the iPhone. Does this also fail if you are viewing the RTT logs during the transfer? 

    Please try to change the NRF_SDH_BLE_GAP_EVENT_LENGTH value in the bootloader sdk_config.h from 6 (default) to 3 to see if it makes DFU more reliable. This will reduce the length of the connection event and limit the max. transfer rate.

Reply
  • Thanks for the additional information. It sounds like the issue might be that your bootloader cannot keep up with the higher transfer rate from the iPhone. Does this also fail if you are viewing the RTT logs during the transfer? 

    Please try to change the NRF_SDH_BLE_GAP_EVENT_LENGTH value in the bootloader sdk_config.h from 6 (default) to 3 to see if it makes DFU more reliable. This will reduce the length of the connection event and limit the max. transfer rate.

Children
Related