Retrieving load addresses of sections from image file only

The firmware image is the output of the dsphex (or hex2000) compiler tool. When I wrote that I see the ".text" or ".cinit" sections, what I really meant was that by searching the compiled functions/sections within the firmware, I can see those sections. For example, by compiling the c_int0 bootstrap function, and then searching for the same words (i.e. E388 <cur+1> 7A89 <var_init> 7A89 <main> 7A89 <C$$EXIT>)  within the firmware, I can conclude that this is the .text section. Same as for the CINIT, by search for <len> <addr> <bytes>, such as 0001 8000 00AD 0001 8001 0FFF ... 0000 0000 I can conclude this is the CINIT section.  There are no strings such as ".cinit" or ".text" within the file, so it's not a COFF file with symbolic information, it's a COFF file stripped of these symbols for imaging purpose.

It may have been used with the -image option in combination with the ROMS property, since the contents are not hex strings, so the output is actually code words for the instructions, for example the first line of the file is

8000 0000 0000 F001 8002 7DFD BE41 BC00 AE60 0600 ...

So basically, it's a direct translation from the assembly (based on IDA pro):

.word 8000
.word 0000
.word 0000
.word F001 (bcndd 8002?)
c_int0:
  sar  ar0, 0FF82h
  bd   0BE41h, *br0+, ar5
  ldp  0
  splk #600h, 60h
...

I'm not sure what the first 4 words are. I assumed the first one was the load address, but doesn't seem to work for the other sections in the firmware. To summarize, I have a binary image which contains the firmware code for an old medical appliance that runs on the TMS320C5, and I'm trying to disassemble the code.  I'm certain it has been compiled with the Code Composer IDE and the RTS50 library, but not sure how it was linked/imaged.

Apologies for my poor explanation. I'll do my best to explain it if unclear.

J.

Using -image makes the hex utility fill in gaps between sections so that the output looks like one long, continuous section, but doesn't change the output format. For instance, when I use hex2000, I get Tektronix format by default:
%4E63C800000000833E000000000000000000000000000000000000000000000000000000000000
The fields are not space-separated, so you have to know where to break it. The first line says:
This line holds data that is 0x4E bytes long, is block type 6 (data), has checksum 0x3c, is loaded at address 0x00000000, and that data is 0x833e followed by all zeros.
hex2000 can produce with spaces between data bytes with either "ASCII-hex" format or "TI-TXT" format, but neither looks quite like you've shown. Are you absolutely sure dsphex generated this file? Are you showing us the exact line as it appears in the image file?

Hmm, I guess I misunderstood what the dsphex tool was doing, because this is really a binary file, not a text file with long strings of digits. It's really made to be written to memory directly. Here's a snapshot taken from IDA. I can't post the entire file due to disclosure agreements. But the screenshot shows the first few words of the file. For example at 0x2A you can see E388 8024 7A89 8031 7A89 8047, so

BCND 802A
CALL 8031
CALL 8047

.

I didn't think dsphex had the ability to emit binary image files; this was a feature added recently, and not to old tools like dsphex. Curious...

Usually binary image files are a verbatim snapshot of the memory; no interpretation is performed. This image is meant to be loaded to a specific address, which is not specified in the file. In this scenario, the initial 0x8000 probably doesn't mean anything to the loader. The trick then is to figure out what the correct starting address is, and everything else should just fall into place.

I doubt that F001 is meant to be treated as code, because it decodes as BCNDD #8002, !Carry, !BIO, which is a pretty weird instruction, especially for startup code. The first several words before 8002 are probably just a data table. 8002 as "SAR ar0, 0FF82h" is plausible, but BE41 as "bd 0BE41h, *br0+, ar5" is weird because br0+ is bit-reversed addressing, normally only used with algorithms like FFT. I'd guess that it, too, is part of data. Are you sure that c_int0 points into this part of code? How do you know the address of c_int0?

Ok, consider this. Below is the C code of the c_int0 function as defined in the library (RTS50.lib) provided with CC:

_c_int0:
	LRLK    AR0,__stack		; set up frame pointer
	LRLK    AR1,__stack		; set up stack pointer
	ROVM				; turn off overflow mode
	SPM     0			; product shift count of zero
	.if	.tms32050
	LDPK	0			; access memory mapped regs
	APL	#0fff9h,PMST		; set NDX = 0 and TRM = 0
	.endif
	SSXM				; set SXM=1 for LALK cinit
	.if	ZERO_WAIT_STATES & .tms32050
	LDPK	0
	SPLK	#0,PDWSR
	.endif
	LALK    cinit			; get pointer to init tables
	ADDK    1
	BZ      skip			; if (cinit == -1)
	CALL    _var_init,AR1		; var_init() 
skip:
	.if	CONST_COPY
	CALL	const_copy
	.endif
	CALL    _main,AR1
	CALL    _abort,AR1		; to never return...
_var_init:
	.if	.tms32025 | .tms3202xx
        ADRK    2			; allocate two words of local memory
        LALK    cinit			; load accumulator with base of table
	LARP    AR0
loop:
	TBLR    *+			; read length 
	ADDK    1
	TBLR    *			; read address
	LAR     AR2,*-			; load variable address into ar2
	LAR     AR3,*,AR3		; load count into ar3
	BANZ    copy,*-,AR2		; check for end of t

Now, once compiled using CC and the included debugger, we get the following machine code:

Now, here's a screenshot of part of the firmware. The c_int0 function prbably starts at 0x801D, with both BF08 ???? BF09 ???? being the two LAR instructions of the c_int0 function, and the 7A89 being the CALL instructions.

Here's a disassembled view of it (labels added by me)

It may have some slight differences, but I'm persuaded the code at 0x801D to be a c_int0 function. It totally possible that the words prior to 0x801D are not part of it. I have no clue about their purpose.

While the stuff at 0x801d does look like code, and it does start with "lar ar0, #948" "lar ar1, #948", notice that the next instruction should be "CLRC OVM", but is "SPM 0". I think you've found a similar function, but not _c_int0.

[Edit: Hmm... is this program actually compiled with the _c_int0 from the RTS, or is it a custom boot routine? ]