• State Not Answered
  • Replies 27 replies
  • Subscribers 63 subscribers
  • Views 4615 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235553
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bootloader DFU stop advertising after updating new firmware

Geek

Hello,

I'm using this example of code (nRF5_SDK_11.0.0_89a8197\examples\dfu\bootloader\pca10040\dual_bank_ble_s132\arm5_no_packs) with my custom board  to perform a dfu. So in this it"s seems to support use of button but in my case there is no button on board so i disabled the below code:

//dfu_start |= ((nrf_gpio_pin_read(BOOTLOADER_BUTTON) == 0) ? true: false);

and all  related function thats use BOOTLOADER_BUTTON.

1. is the desactivation of the button code can run the app as if there was no button on board or there is another trick to enter the DFUmode without using the button. ? 

2. I have another issue ; i have downloaded an hex file over the air, the DFU work well , and bootloader give control to the application but stop advertinsing.as "DfuTrgt" si i can't perform another dfu . Do you have any idea where and how to change code  in order to perform dfu again even if application ?

Best regards

Parents
  • 0

    Hi Geek, 

    Yes, we have the buttonless example that can do exactly what you looking for. Read about it here and here. I have a note about it in my blog here as well. 

  • 0 in reply to Hung Bui

    Hi Hung Bui,

    Actually i can perform with the example provideed in the sdk11, i have only  disable the use of button and it work as i expected. I would like to use sdk11 not sdk13 with the buttonless exemple. So im looking for solution with the use of sdk11 exemple. 

    I have already read your article about buttonless dfu but it doesn't fit actually my need. So, i look for solution of  why i can't perform more DFU and why my bootloader DFU stop adverttising once application start runing ?

  • 0 in reply to Hung Bui

    Hi Hung Bui,

    I have added  share memory  flash adrress between bootloader and application.So its a simple way to force bootloader to  enter bootloader mode by  writing  "true" value in to this memory adress from the application and make a prompt test to the above "flag" variable.

    Now Im facing another issue, it's about power consumption. The software that's im use to send app image ,transmitt about 200 Byte every 1s and my app image is about 33KByte, So i spend more 3 min to download all the image. 

    During the download, Bootloader DFU draw 5mA every 1s, so for 3min I consume 900 mA. 

    My question is, there is any way to reduce power consumption ?

  • 0 in reply to Geek

    Usually we use a retention register instead of a shared RAM area but I think it would be fine. 

    200 byte per second is very low. I would assume that it's the limitation on the peer device, not because of the nRF52 ? 

    I'm not sure I understand what you meant by 5mA every 1s. Do you mean 5mAh  ? Current can't be measured over time.

    Or it's the constant 5mA current you are seeing ? 

    Are you using our unmodified bootloader ? 

  • 0 in reply to Hung Bui

    Hi,

    thank you for replay. I have attached some screenshot to show current drawing in different phase bootloader runing.

    In this picture, bootloader continue to consume current even if is waiting for image packets (Here Peer device doesn't start sending image file).

     

    Here, peer device start sending packet

    and after finshed image downloding there is a current peak  consumption due to the transition from bootloader to the application

    i hope it a bit clear now. 

    "Are you using our unmodified bootloader ? "

    yes, i m using unmodified bootloader.

  • 0 in reply to Geek

    Hi, 

    The image doesn't show the current (it shows the voltage drop ? ) so I don't know what's the current is.

    When you mentioned " is waiting for image packet", is the connection established or not ? In both case, the bootloader will either advertise , or have to wake up to handle the connection (even though there is no data transfer) so it's normal to periodically have some peak current.

    The long period after the image transfer finish could be the period where the image is swapped the CPU has to be active to do flash operation. 

  • 0 in reply to Hung Bui

    sorry , i missed to tell that i m using small resistor(100 ohm) in line with power supply (3,6 V). So the average current is  7,8 mA .

    "Is waiting for image packet" means that  the connection is not established yet . That's why im totally surprised that bootloader still consuming current even though there is no connection .

Reply Children
Related