DAPLink icon indicating copy to clipboard operation
DAPLink copied to clipboard
verified publisher icon ARMmbed

Drag-and-drop hex decoding seems to be invalid

Open nordicjm opened this issue 3 years ago • 1 comments

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
<OVERFLOW>
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

nordicjm avatar Jun 29 '22 11:06 nordicjm

In all the time I've worked with this firmware, it's probably one of the least successful code bases I've seen. The keil build of this is so janky, things just do not work, for reasons unknown. Building a gcc version actually produces a stable application, however you can't then upgrade to a gcc interface from a keil bootloader (0254 to 0258), it seems to miss programming the checksum at the end of the file and fail to boot the new image, for reasons unknown. Upgrading between keil interface builds seems to be based on pure luck. The above issue with programming the hex file seems to be caused by the CDC USB descriptor which will just prevent a file transfer that is in progress. Lots of magic numbers all over the place that actually have no relation to other values e.g. CDC buffer which is set at 64 bytes.

nordicjm avatar Jul 06 '22 16:07 nordicjm