programmer - fails with certain .hex files

[orgua]

TLDR

Programmer is miss-guided by padding / alignment of .hex-file.

https://developer.arm.com/documentation/ka003694/latest

helps to realign the .hex. Store config into file 'srec_cfg'

# BL51 hex files are not sorted for ascending addresses. Suppress this warning
-disable-sequence-warning
# load input HEX file
build.hex -Intel
# fill all incomplete 16-bit words with 0xFF. The range is limited to the application
-fill 0xFF -within build.hex -Intel -range-padding 4
# generate hex records with 16 byte data length (default 32 byte)
-Output_Block_Size=16
#generate 16-bit address records. Do no use for address ranges > 64K
-address-length=2
# generate a Intel hex file
-o buildPadded.hex -Intel

install and run srec_cat

sudo apt install srecord
srec_cat @srec_cfg

TODO: integrate into shepherd

Long Version

investigation so far:

• firmwares from https://github.com/orgua/shepherd-targets/releases work, except rf-survey / trafficbench
• trafficbench is built with segger tools (automatically in github workflow)
• flashing the hex onto the nRF triggers a verification error (read-back of written data)
  • ignoring that verification-error leads to a write-error right after
• programmer now bubbles up address and value, see below
• tools used
  • latest shepherd dev-branch
  • targets fw from release v0.3.1

Debug output

Will set pru0-firmware to 'am335x-pru0-programmer-SWD-fw'
Shared memory address:  0x9CA00000, size: 15607808 byte
Samples per buffer:     10000
Number of buffers:      64
Buffer period:          0.100 s
Size of 1 Buffer:       243872 byte
wrote Firmware-Data to SharedMEM-Buffer (size = 120989 bytes)
set programmerCTRL
        target = 'nrf52'
        datarate = '500000'
        pin_tck = '5'
        pin_tdio = '4'
        pin_dir_tdio = '10'
        pin_tdo = '0'
        pin_tms = '0'
        pin_dir_tms = '0'
Programmer initialized, will start now
Programming in progress,        pgm_state = init, shp_state = reset
Programming in progress,        pgm_state = running - 4640 B written, shp_state = reset
Programming in progress,        pgm_state = running - 10256 B written, shp_state = reset
Programming in progress,        pgm_state = running - 15864 B written, shp_state = reset
Programming in progress,        pgm_state = running - 21468 B written, shp_state = reset
SystemError - Failed during Programming, p_state = error (-3)
Programming - Procedure failed - will exit now!
        shepherdState   = idle
        programmerState = error (-3)
        programmerCtrl  = ['nrf52', '500000', '5', '4', '10', '0', '0', '0']
PROGRAMMER-WRITE-ERROR: ihex to target @0x5FB7, data=7238995 [0x6E7553]
Now exiting ShepherdIO

Panicking Line in Programmer-Code

Section in Hex (Line 1570, +-3 Lines)

:105F90004108300842083608252D32352E32357337
:105FA00020252D32352E32357320666C75736820AE
:075FB0006275666665720070
:105FB70053756E004D6F6E0054756500576564002C
:0D5FC7005468750046726900536174000053
:105FD4004108300842083608252D32352E323573F3
:105FE40020252D32352E3235732066696E616C6939

Decoded iHex

Byte Count: x10
Address:    x5FB7
RecordType: x00
Data:       x53756E004D6F6E005475650057656400
Checksum:   x2C

Error happens right at the beginning of that data-segment.
NOTE: the offset is !=mod4 here, as there are 7 bytes written in der prev. hex-line. According to nRF-Doc Section 4.3.1 that is a problem as only whole 32bit-values can be written.

Removing both write & verify error-panicks the programmer runs till the end - but the firmware is not working. last data-segment in hex-file is at 0xA58A which would be 42378 in base10 and corresponds to the blocks written (as reported by the interface).

Programmer initialized, will start now
Programming in progress,        pgm_state = init, shp_state = reset
Programming in progress,        pgm_state = running - 3088 B written, shp_state = reset
Programming in progress,        pgm_state = running - 6824 B written, shp_state = reset
Programming in progress,        pgm_state = running - 10544 B written, shp_state = reset
Programming in progress,        pgm_state = running - 14280 B written, shp_state = reset
Programming in progress,        pgm_state = running - 18012 B written, shp_state = reset
Programming in progress,        pgm_state = running - 21744 B written, shp_state = reset
Programming in progress,        pgm_state = running - 28012 B written, shp_state = reset
Programming in progress,        pgm_state = running - 41176 B written, shp_state = reset
Finished Programming!
        shepherdState   = idle
        programmerState = idle
        programmerCtrl  = ['nrf52', '500000', '5', '4', '10', '0', '0', '0']

Reducing data-rate from 500k to 300k, 200k, 100k works but triggers the same verification-error.

Try to fix Alignment

The Segger-tools seem to produce incompatible hex-files. Unfortunately a generic objcopy makes the same error, only later in the hex. Even with special commands.

objcopy -O ihex build.elf build.hex --file-alignment 4 --section-alignment 4
objcopy -O ihex build.elf build.hex --gap-fill 0x00 --srec-len 0x08 --file-alignment 0x04 --section-alignment 0x04 

[orgua]

workaround added in latest /dev-branch

https://github.com/orgua/shepherd/blob/dev/software/python-package/shepherd_sheep/__init__.py#L139