arm-none-eabi-objcopy: Generating SREC file for stand alone programming of LPC-824 devices

[lpcware]

Content originally posted in LPCWare by lonwalker on Thu Mar 05 14:45:50 MST 2015
Hello all,

I am trying to generate a hex file in SREC format for a PE-Micro Cyclone programmer to utilize for programming LPC824 devices.    I used the following Xpresso (v7.6) post-build step to somewhat of success:

arm-none-eabi-objcopy -O srec ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.s19


I am however finding out that the Programmer is failing a read-verify after programming locations 001C-001F.     I learn from the LPC824 data sheet that these locations are reserved for Cotrex-M0+ exception vector for validating the first 7 vector locations.  The 8 location (vector 7) should contain a 2's complement sum of the first 7 vectors.

My programmer device, PEMicro Cyclone for ARM, *does* appear to program everything correctly, but complains during the read-verify after programming that the expected data for vector 7 is 0000 0000h instead of what the device actually has;  something like 1DDB FFFF.

Looking at the objcopy generated SREC programming file data the utility is setting the expected data for locations 001C-001F to zeros instead of the 2's complement of checksum of vectors 0-6:

S017000053593930312D4261724C6974653832342E73313929
S11300000020001049010000C9010000D1010000D6
S113001000000000000000000000000000000000DC


I have not found any 'true'  PDF type documentation on arm-none-eabi-objcopy utility other than the command line help- Is there any that anyone knows of?.

Is there a way to make the utility compute the checksum of the first 7 vectors, 2's complement that, and then generate SREC data for vector 7 (address locations 001c-001f) ???


Maybe there is something else going on here I am not just aware of???, but as always in engineering- time is of the essence here.

Thanks in  advance for any help you could lend,
Lon

[lpcware]

Content originally posted in LPCWare by lonwalker on Fri Mar 06 16:11:23 MST 2015
Good catch R2D2.  I did not notice the difference between environment variable ${BuildArtifactFileName} and ${BuildArtifactFileBaseName}.
I have corrected that and it looks like I have a srec file is as expected- number of bytes correct and a checksum for the Vector 7 byte locations.
Programmer now read-verifies after programming.

Best regards!

[lpcware]

Content originally posted in LPCWare by R2D2 on Fri Mar 06 14:35:38 MST 2015
Your bin is OK  :)

Your srec is faulty because you generate it from axf  :((

---

Quote:
arm-none-eabi-objcopy -v -I binary -O srec SY901-BarLite824[color=#f00].axf[/color] SY901-BarLite824.s19

---

As shown above input file has to be the bin file here  ;-)

Sample:

---

Quote:
copy from `LPC15_BL_APP.axf' [elf32-littlearm] to `LPC15_BL_APP.bin' [binary]
Created checksum 0xfdffb306 at offset 0x1c in file LPC15_BL_APP.bincopy from `LPC15_BL_APP.bin' [binary] to `LPC15_BL_APP.srec' [srec]

---

[lpcware]

Content originally posted in LPCWare by lonwalker on Fri Mar 06 14:00:42 MST 2015
Find attached the Binary file and the generated Hex file that seems to be too big.
Adding the '-v' verbose switch to the last OBJCOPY.   obtained the  following console result:



Building target: SY901-BarLite824.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"C:\Users\lonni219\Documents\PROJECT-NXP\SY901-LiteBar824\SY901-BarLite824\lpc_chip_82x-V215_REV1\Debug" -Xlinker -Map="SY901-BarLite824.map" -Xlinker --gc-sections -mcpu=cortex-m0 -mthumb -T "SY901-BarLite824_Debug.ld" -o "SY901-BarLite824.axf"  ./src/BITest.o ./src/Init.o ./src/Inputs.o ./src/Modes.o ./src/SY901LiteBar.o ./src/SysTick.o ./src/cr_startup_lpc82x.o ./src/crp.o ./src/inmux.o ./src/iocon.o ./src/mtb.o ./src/swm.o   -llpc_chip_82x-V215_REV1
Finished building target: SY901-BarLite824.axf

make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size "SY901-BarLite824.axf" ; arm-none-eabi-objcopy -v -O srec "SY901-BarLite824.axf" "SY901-BarLite824.S1" ; arm-none-eabi-objcopy -v -O binary "SY901-BarLite824.axf" "SY901-BarLite824.bin" ; checksum -p LPC824 -d "SY901-BarLite824.bin" ; arm-none-eabi-objcopy -v -I binary -O srec SY901-BarLite824.axf SY901-BarLite824.s19
   text   data    bss    dec    hexfilename
   6112      8    192   6312   18a8SY901-BarLite824.axf
copy from `SY901-BarLite824.axf' [elf32-littlearm] to `SY901-BarLite824.S1' [srec]
copy from `SY901-BarLite824.axf' [elf32-littlearm] to `SY901-BarLite824.bin' [binary]
Created checksum 0xefffdb1d at offset 0x1c in file SY901-BarLite824.bincopy from `SY901-BarLite824.axf' [binary] to `SY901-BarLite824.s19' [srec]

[lpcware]

Content originally posted in LPCWare by R2D2 on Fri Mar 06 12:37:35 MST 2015
Could be useful to post your bin file  ;-)

And try:

---

Quote:

arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"
checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.bin"
arm-none-eabi-objcopy -v -I binary -O srec "${BuildArtifactFileBaseName}.bin" "${BuildArtifactFileBaseName}.srec"

---

[lpcware]

Content originally posted in LPCWare by lonwalker on Fri Mar 06 11:22:52 MST 2015
THANKS- CLOSER, BUT STILL NOT QUITE WORKING FOR ME:

Again, is there ANY .PDF documentation covering the objcopy utility???    The command line help is very top level vague.
...

So I am now doing the following processes as outlined in FAQs reviewed; 
1..  I do a AXF to SREC (just to see what is generated that way):
arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.S1"


2.. I do a AXF to SREC, then AXF to BIN, CHECKSUM BIN, then BIN TO SREC

arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"
checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.bin"
arm-none-eabi-objcopy -I binary -O srec ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.s19


The S19 data generated indicates that checksum data is now defined for address 001C - 001F is 34000000,  I have yet to confirm if this is correct?  
The srec data for this range:
S017000053593930312D4261724C6974653832342E73313929
S2140000007F454C4601010100000000000000000092
S214000010 020028000100000049010000 34000000 32



Problem now is that my Cyclone programmer software now complains during of its generation of its data program image that it finds an invalid detected address in range:
Checking range of S records.    Invalid address detected.
Invalid addresses in srecord block from #000080000 to $0000800F.



[u]Upon Analyzing the srec files generated from the steps above:  
[/u]The first srec generation from the AXF directly only uses S1 records (2 byte offset addresses); and details data for the range of 0-17EB hex

The binary file of the AXF conversion generates a file 07EC bytes big--- and is what I would of expected.
The binary FILE to srec generation file uses S2 type records (3 byte offset addresses), but goes 'overboard' with defining data in the ranges of: 0 to like 033C07 hex.

WHY????  The binary file was only 07ECh bytes big??

Generated srec file snipet from the binary file:
S017000053593930312D4261724C6974653832342E73313929
S2140000007F454C4601010100000000000000000092
S214000010 020028000100000049010000 34000000 32
S2140000202814030002020005340020000300280004
S21400003012000F0001000000008000000000000019
.
.  (bunch of contiguous data between)
.
S214033BE06573005F5F61656162695F696469766DCD
S214033BF06F6400436869705F53595343544C5F5076
S20D 033C00 6F776572446F776E005E
S804000000FB




Thanks again for any help you can lend.

Lon

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 05 14:57:50 MST 2015
Documentation for all the tools is in the IDE. Help->Help Contents and search for objcopy.

To create checksum, see:
http://www.lpcware.com/content/faq/lpcxpresso/image-checksums

You may also find these are useful:
http://www.lpcware.com/content/faq/lpcxpresso/post-processing-linked-application
http://www.lpcware.com/content/faq/lpcxpresso/generating-srec-binary-and-ihex-files

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Mar 05 14:55:04 MST 2015
Did you try to generate a bin + checksum before?

http://www.lpcware.com/content/faq/lpcxpresso/image-checksums