• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 67 subscribers
  • Views 3456 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 105020
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

Is there a packet size limitation for the bootloader?

Anne van Rossum

Currently I can upload new application firmware smoothly (I use the dual bank setup). However, I have to use packets of size 20, so this takes a long time.

Is there actually such a packet limitation? If I use packets of, for example, size 40, or anything bigger than 20, I get the following stack trace:

 bt
Read 1 bytes @ address 0x0003B6F4 (Data = 0x2E)
Read 1 bytes @ address 0x0003B6F5 (Data = 0x2E)
#0  app_error_handler (error_code=8, line_num=820, p_file_name=0x3b6f4 "."...) at ../main.c:119
Read 4 bytes @ address 0x00035C38 (Data = 0xE001E002)
#1  0x00035c38 in dfu_transport_close () at ../dfu_transport_ble.c:820
Read 4 bytes @ address 0x00036044 (Data = 0x617B1C03)
Reading 64 bytes @ address 0x20003E40
#2  0x00036044 in bootloader_dfu_update_process (update_status=...) at ../bootloader.c:199
Read 4 bytes @ address 0x00034F2A (Data = 0xB00246BD)
#3  0x00034f2a in dfu_reset () at ../dfu_dual_bank.c:455
Read 4 bytes @ address 0x0003564C (Data = 0xE053E054)
Reading 64 bytes @ address 0x20003E80
#4  0x0003564c in on_dfu_evt (p_dfu=0x20002c24 <m_dfu>, p_evt=0x20003ea4) at ../dfu_transport_ble.c:478
Read 4 bytes @ address 0x000366A8 (Data = 0x1C3BE050)
Reading 64 bytes @ address 0x20003EC0
#5  0x000366a8 in on_ctrl_pt_write (p_dfu=0x20002c24 <m_dfu>, p_ble_write_evt=0x20002a9c <EVT_BUFFER.7592+8>)
    at /opt/nrf51_sdk/v6/nrf51822//Source/ble/ble_services/ble_dfu.c:284
Read 4 bytes @ address 0x0003678E (Data = 0x60BB1C03)
#6  0x0003678e in on_rw_auth_req (p_dfu=0x20002c24 <m_dfu>, p_ble_evt=0x20002a94 <EVT_BUFFER.7592>)
    at /opt/nrf51_sdk/v6/nrf51822//Source/ble/ble_services/ble_dfu.c:353
Read 4 bytes @ address 0x00036978 (Data = 0x46BD46C0)
#7  0x00036978 in ble_dfu_on_ble_evt (p_dfu=0x20002c24 <m_dfu>, p_ble_evt=0x20002a94 <EVT_BUFFER.7592>)
    at /opt/nrf51_sdk/v6/nrf51822//Source/ble/ble_services/ble_dfu.c:483
Read 4 bytes @ address 0x0003590C (Data = 0x1C18687B)
Reading 64 bytes @ address 0x20003F00
#8  0x0003590c in ble_evt_dispatch (p_ble_evt=0x20002a94 <EVT_BUFFER.7592>) at ../dfu_transport_ble.c:644
Read 4 bytes @ address 0x0003AA38 (Data = 0x330F1C3B)
#9  0x0003aa38 in intern_softdevice_events_execute () at /opt/nrf51_sdk/v6/nrf51822//Source/sd_common/softdevice_handler.c:133
Read 4 bytes @ address 0x0003AB88 (Data = 0xB00246BD)
#10 0x0003ab88 in SWI2_IRQHandler () at /opt/nrf51_sdk/v6/nrf51822//Source/sd_common/softdevice_handler.c:310
#11 <signal handler called>
Read 4 bytes @ address 0x20003F4C (Data = 0x61000000)
Reading 64 bytes @ address 0x20003F40
Read 4 bytes @ address 0x0000F842 (Data = 0xBF20BF40)
#12 0x0000f842 in ?? ()
Read 4 bytes @ address 0x0000119A (Data = 0x9801B401)
#13 0x0000119a in ?? ()
Read 4 bytes @ address 0x0000119A (Data = 0x9801B401)
#14 0x0000119a in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  • 0

    Writing to a standard characteristic is limited to 20 bytes. The MTU of the packet is 23 bytes and there are 3 bytes of overhead imposed by the protocol. BLE does provide for writing long characteristics and I believe the later versions of the Nordic stack supports them. Here is a rather old question on the topic that may be useful:

    Old question

    So you may want to look into adding the use of long writes to your DFU

  • 0 in reply to John

    I would be surprised if that would be actually the reason. Sending the individual packets is actually fine. There is only a problem at the very end of receiving the entire payload. I will check anything w.r.t. long writes within the bootloader software though.

  • 0

    With the current SoftDevice the payload is limited to 20 bytes.

    Long writes will not change that, please see this.

    The time it takes to do DFU is affected by other factors than the payload size, please see this for more information.

    One thing that should quicken the procedure is to increase the number of packets between each packet receipt notification. From the Master Control Panel DFU script:

    # NOTE:  If packet receipt notification is enabled, a packet receipt
#        notification will be received for each 'num_of_packets_between_notif'
#        number of packets.
#
# Configuration tip: Increase this to get lesser notifications from the DFU
# Target about packet receipts. Make it 0 to disable the packet receipt
# notification
num_of_packets_between_notif = 10

    This can also be changed in the DFU Options in the nRF Master Control Panel for Android.

  • 0 in reply to Petter Myhre

    The DFU upload functionality embedded in the Android smartphone app fails as well. I don't care about size limitations, but I do care about my program segfaulting due to configuration options (I assumed them to be size-related) on the smartphone / laptop side.

    Note that this is just the default bootloader with only a few adaptations: github.com/.../nrf51-dfu-bootloader-for-gcc-compiler, fork from github.com/.../nrf51-dfu-bootloader-for-gcc-compiler. It is not that I changed a lot of stuff. So, perhaps it's nice of someone from Nordic would take a second look to check if everything is still working okay. :-)

  • 0 in reply to Petter Myhre

    Why do you ask about size limitations if you don't care about them? I think this issue us better suited for the MyPage support portal, please consider adding a case there.

Related