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?)

[Anne van Rossum]

There is "something" in the configuration of the DFU uploader in the Nordic app that makes the Nordic bootloader fail. I see that the Nordic bootloader segfaults if I use long writes in a python script. I think it is size-related. You say it is not. It is not my code. Please, see this just as bug report. I'm not here to start a discussion.

[Petter Myhre]

I'm just trying to say that long writes will not improve the throughput. We want to help you figuring out what is causing the fault, therefore I asked you to separate case/question for it. Then you can include the necessary details of what changes you have done to the bootloader and what your setup is on the central side.

[Anne van Rossum]

Okay, although I prefer it to be on a public place, so others can see it as well. :-)