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
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.
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'
install and run srec_cat
TODO: integrate into shepherd
Long Version
investigation so far:
Debug output
Panicking Line in Programmer-Code
Section in Hex (Line 1570, +-3 Lines)
Decoded iHex
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).
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.