Thanks for the clarification. If I understand correctly the toolchain you are using is able to produce working ELF (.x) output. If this is the case then I suggest that you output this format from the linker and then add another build phase at the end which calls objcopy to convert the ELF output to s-record. The command should be something like
h8300-elf-objcopy.exe -I elf32-h8300 test.x -O srec test.mot
Hope this helps.
: Hi GA,
: Thank you for reply.
: Here is a better description of the
: problem which may help confirm that
: our problem is related to
: Situation : HEW rev3.01.05.001
: KPIT GNUH8 ELF v0601
: The linker has been set to produce
: Motorola s-record files and an extra
: built phase added which calls a
: script to convert the .mot file to a
: binary file ready for transfer to
: the target hardware.
: The project has compiled before on
: pervious version of HEW / GNUH8 and
: has worked fine.
: Now we have a problem.If we clean
: the project (which deletes all the
: object files .o/.mot .x etc) and
: rebuild we get a .mot file but it
: contains elf data. THIS IS WRONG!
: If we clean the project, set the
: linker to make elf file we get a .x
: file with elf in it (as expected),
: if we then set the linker to make
: s-record and build it will make a
: .mot containing s-record data which
: However if we then make changes to
: the source and recompile the .mot
: file does not reflect this changes.
: So to make an uptodate .mot file we
: currently have to compiler twice,
: one linking to .x and then again to
: .mot this is slowing down
: development a lot.
: From the reply you have got it
: sounds like the ‘h8300-elf-objcopy’
: stage does not get called to remake
: the .mot from the .x
: the extra build phase may be
: confusing the ‘make’ process (we are
: not using the HEW option to generate
: a make file) but even with it
: disabled the problem persists.
: I have tried HEW 4.02 and the latest
: GNUH8 v0602 on a different PC, the
: project compiled but did not produce
: code that worked, I did not notice
: if the problem above was present. I
: suspect the problem with
: HEW4.02/GNUH8 v6002 may be due to
: the mixed C and inline assembler in
: one part of out project. We dare not
: risk breaking our development
: environment any further till current
: projects are delivered.