Drag-and-drop hex decoding seems to be invalid

I've got an old project based on DAPLINK version 0254 which is having difficulties when programming a zephyr hex file to an nRF52840 target. I've added debugging in to both the flash programming algorithm (custom) and enabled flash_decoder debugging, and the output does not tally with the input, the hex file starts at address 0x0, but for some reason the first command sent to the remote device is to erase sector 0xe000. I've seen that the intelhex.c file has changed since the version I had, so I've replaced the file in my build with the current version in main, which has made no difference. The top part of the hex file looks like this:
```
:020000040000FA
:10000000706000208D4200004BAB0000E142000018
:10001000E1420000E1420000E14200000000000077
:10002000000000000000000000000000514000003F
:10003000E142000000000000094000005BA6000053
:100040004D4200004D4200004D4200004D42000074
:100050004D4200004D4200004D4200004D42000064
:100060004D4200004D4200004D4200004D42000054
:100070004D4200004D4200004D4200004D42000044
:100080004D4200004D4200004D4200004D42000034
:100090004D4200004D4200004D4200004D42000024
:1000A0004D4200004D4200004D4200004D42000014
:1000B0004D4200004D4200004D4200004D42000004
:1000C0004D4200004D4200004D4200004D420000F4
:1000D0004D4200004D4200004D4200004D420000E4
:1000E0004D4200004D4200004D4200004D420000D4
:1000F0004D4200004D4200004D4200004D420000C4
:100100007BB972B90029BEBF00204FF0004106E064
```
The flash_decoder output gives this:
```
flash_decoder_open()
flash_decoder_write(addr=0xaf40, size=0xb0)
initial_addr=0xaf40
buffering 48 bytes
Buffering complete, setting flash_type=3
flash_start_addr=0x0
flash_manager_init ret 0
Flushing buffer initial_addr=0xaf40, flash_buf_pos=48, flash_manager_data ret=0
Writing data, addr=0xaf70, size=0x80, flash_manager_data ret 0
flash_decoder_write(addr=0xaff0, size=0xc0)
Writing data, addr=0xaff0, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xb0b0, size=0xb0)
Writing data, addr=0xb0b0, size=0xb0, flash_manager_data ret 0
flash_decoder_write(addr=0xb160, size=0xc0)
Writing data, addr=0xb160, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xb220, size=0xc0)
Writing data, addr=0xb220, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xb2e0, size=0xb0)
Writing data, addr=0xb2e0, size=0xb0, flash_manager_data ret 0
flash_decoder_write(addr=0xb390, size=0xc0)
Writing data, addr=0xb390, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xb450, size=0xc0)
```
Debugging of my flash algorithm gives this:
```
Iinit0.0.1
ea000
Iinit0.0.2
pac00.1024.20004000
Iinit0.0.3
vac00.1024.20004000
Iinit0.0.1
eb000
Iinit0.0.2
pb000.1024.20004000
Iinit0.0.3
vb000.1024.20004000
Iinit0.0.2
pb400.1024.20004000
Iinit0.0.3
vb400.1024.20004000
Iinit0.0.2
pb800.1024.20004000
Iinit0.0.3
vb800.1024.20004000
Iinit0.0.2
pbc00.1024.20004000
Iinit0.0.3
vbc00.1024.20004000
Iinit0.0.1
ec000
Iinit0.0.2
pc000.1024.20004000
Iinit0.0.3
vc000.1024.20004000
Iinit0.0.2
pc400.1024.20004000
Iinit0.0.3
vc400.1024.20004000
Iinit0.0.2
pc800.1024.20004000
Iinit0.0.3
vc800.1024.20004000
Iinit0.0.2
pcc00.1024.20004000
Iinit0.0.3
vcc00.1024.20004000
Iinit0.0.1
ed000
Iinit0.0.2
pd000.1024.20004000
Iinit0.0.3
vd000.1024.20004000
Iinit0.0.2
pd400.1024.20004000
Iinit0.0.3
vd400.1024.20004000
Iinit0.0.2
pd800.1024.20004000
Iinit0.0.3
vd800.1024.20004000
```
where v = verify, I = init, e = erase, p = program, followed by the address, then the size, and the RAM buffer location.

The process seems to finish early too, the final address in the hex file is 0xc951d but as can be seen from the debug, it ends before this (I do eventually get a transfer timeout error when the msd drive reboots):
```
flash_decoder_write(addr=0xc9190, size=0xb0)
Writing data, addr=0xc9190, size=0xb0, flash_manager_data ret 0
flash_decoder_write(addr=0xc9240, size=0xc0)
Writing data, addr=0xc9240, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xc9300, size=0xc0)
Writing data, addr=0xc9300, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0xc93c0, size=0xb0)
Writing data, addr=0xc93c0, size=0xb0, flash_manager_data ret 0
flash_decoder_write(addr=0xc9470, size=0xac)
Writing data, addr=0xc9470, size=0xac, flash_manager_data ret 0
flash_decoder_close()
flash_manager_uninit ret 0

Iinit0.0.1
ec8000
Iinit0.0.2
pc8000.1024.20004000
Iinit0.0.3
vc8000.1024.20004000
Iinit0.0.2
pc8400.1024.20004000
Iinit0.0.3
vc8400.1024.20004000
Iinit0.0.2
pc8800.1024.20004000
Iinit0.0.3
vc8800.1024.20004000
Iinit0.0.2
pc8c00.1024.20004000
Iinit0.0.3
vc8c00.1024.20004000
Iinit0.0.1
ec9000
Iinit0.0.2
pc9000.1024.20004000
Iinit0.0.3
vc9000.1024.20004000
Iinit0.0.2
pc9400.1024.20004000
Iinit0.0.3
vc9400.1024.20004000
```

I've also tried re-saving the hex file in the other hex style and loading it:
```
:20000000706000208D4200004BAB0000E1420000E1420000E1420000E1420000000000009F
:2000200000000000000000000000000051400000E142000000000000094000005BA60000C2
:200040004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D42000028
:200060004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D42000008
:200080004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D420000E8
:2000A0004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D420000C8
:2000C0004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D420000A8
:2000E0004D4200004D4200004D4200004D4200004D4200004D4200004D4200004D42000088
:200100007BB972B90029BEBF00204FF0004106E008BF00281CBF6FF000414FF0FF3000F08C
:2001200057B8ADF1080C6DE904CE002909DB002B1ADB00F04FF8DDF804E0DDE9022304B01A
:200140007047404261EB4101002B1BDB00F042F8DDF804E0DDE9022304B0404261EB410125
:20016000524263EB43037047524263EB430300F031F8DDF804E0DDE9022304B0404261EB39
```
And this looks a bit better:
```
flash_decoder_open()
flash_decoder_write(addr=0x0, size=0xc0)
initial_addr=0x0
buffering 48 bytes
Buffering complete, setting flash_type=3
flash_start_addr=0x0
flash_manager_init ret 0
Flushing buffer initial_addr=0x0, flash_buf_pos=48, flash_manager_data ret=0
Writing data, addr=0x30, size=0x90, flash_manager_data ret 0
flash_decoder_write(addr=0xc0, size=0xe0)
Writing data, addr=0xc0, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x1a0, size=0xc0)
Writing data

flash_decoder_write(addr=0x260, size=0xe0)
Writing data, addr=0x260, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x340, size=0xe0)
Writing data, addr=0x340, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x420, size=0xc0)
Writing data, addr=0x420, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0x4e0, size=0xe0)
Writing data, addr=0x4e0, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x5c0, size=0xe0)
Writing data, addr=0x5c0, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x6a0, size=0xc0)
Writing data, addr=0x6a0, size=0xc0, flash_manager_data ret 0
flash_decoder_write(addr=0x760, size=0xe0)
Writing data, addr=0x760, size=0xe0, flash_manager_data ret 0
flash_decoder_write(addr=0x840, size=0xe0)
```

It seems that the first file pasted starts writing at the wrong offset, if the original zephyr hex file is then pasted again, it does the same thing, however if instead, the other hex file is pasted, it will write the file properly to the device. This doesn't work if I erase the flash (using a drag-and-drop file) however, so I assume it's still skipping parts when writing or there is something weird going on with reading the input file data. Host mcu for this is an atmel sam3u2c and target micro is nordic nRF52840, host system is linux (debian 11, 64-bit). Any suggestions as to what could be the cause/resolution for this?

Using pyocd with the programmer does not have any of these issues when using the custom flash algorithm file, it programs successfully

Start by comparing the drag-and-drop path in flash_decoder with intelhex.c, using the two logged inputs and addresses as the reproduction evidence. Compare its behavior with the successful pyocd programming path and trace why the first file begins at 0xaf40 or stops before 0xc951d. Done means the original Zephyr hex file is programmed through drag-and-drop without skipped regions or a transfer timeout.

Written by the indexing model from the issue text.