C6745 Emulation problem

Hi Daniel,

The behavior I am seeing is the result of trying to load and run code. I would expect the emulator to start in the RTS C set-ups and then to jump to "main:" in my code. Am I missing something in one of my files? I wasn't able to load them here (kept getting "website not found"), so I've appended the relevant pieces here. The gel file is just TTO.gel with the non-6745 LPSC parts stripped out.

Thanks,

Ron

//////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////
//                       //
//             CT-610dspMain.h         //

#ifndef CT610DSP_
#define CT610DSP_

#endif /*CT610DSP_*/

//////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////
//                       //
//             CT-610dspMain.c         //

void main (void){
 while (1){
  asm(" nop 10");
 }
}
;*********************************************************************************************
;**                       **
;**            CT-610dspMain.asm         **

  .cdecls C,LIST,"CT610dsp.h"

  .global _c_int00
   
;*********************************************************************************************
;*          INITIALIZATION           *
;*********************************************************************************************

Init:
;  ret

_LCD_int:

_berr_interrupt:

__intr_handler:

;*********************************************************************************************
;*             INTERRUPT VECTORS           *
;*********************************************************************************************
;
; Interrupt vectors.
;
; set trap=vector number
; call sw_trap and passing trap
 
 .sect ".vecs"
__vectors:

 b _c_int00   ; 0, Reset
 nop 5

  .end

/****************************************************************/
/*                                                              */
/*            LINKER command file for CT-610     */
/*                                                              */
/****************************************************************/

-l rts6740.lib
/*-l ..\..\Plat\driver.lib*/

-stack           0x00000800
-heap            0x00000800

MEMORY
{  
 DSP_L2_RAM_txt:     ORIGIN = 0x00800000 LENGTH = 0x00030000
 DSP_L2_RAM_data:    ORIGIN = 0x00830000 LENGTH = 0x00010000    
 DSP_L1P_RAM:  ORIGIN = 0x00E00000 LENGTH = 0x00008000  /*32K -4K*/
 DSP_L1D_RAM:      ORIGIN = 0x00F00000 LENGTH = 0x00008000  /*32K -4K*/
 shared_ram:       ORIGIN = 0x80000000 LENGTH = 0x00020000               
}

SECTIONS
{
 .vecs       > DSP_L2_RAM_txt
 .text_L1P   > DSP_L2_RAM_txt
    .text    > DSP_L2_RAM_txt    
    .const      > DSP_L2_RAM_txt
    .bss        > DSP_L2_RAM_txt
    .bss_L2     > DSP_L2_RAM_txt
    .far        > DSP_L2_RAM_txt
    .switch     > DSP_L2_RAM_txt
    .stack      > DSP_L2_RAM_txt
    .data       > DSP_L2_RAM_txt
    .cinit      > DSP_L2_RAM_txt
    .sysmem     > DSP_L2_RAM_txt
    .cio        > DSP_L2_RAM_txt
}

 

Ron,

I'm not sure what the TTO.gel file contains, but, if we assume that it is not somehow messing things up, when you try to load the executable file it should bring you to either the application's actual entry point (the _c_int00 symbol) or to the main function, depending on the CCS settings.

Can you provide a screenshot of what happens when you try to load your .out file?

Regards, Daniel

Hi Daniel, Thanks for your tip. I dug into the debug set-up and found that the "Reset the target on a program load or restart" switch was turned on. This probably caused the jump to the boot. It now gets to the _c_int00 point. If I try to step or run to main from that point, it again jumps into the boot. Below is a disassembly of the _c_int00 code. Since it starts with a .word, it doesn't look like real code to me. I don't know if this gets generated to the compiler or just linked in as an object file. Thanks, Ron c_int00: 0x00800A60: FE2A0783 .word 0xfe2a0783 0x00800A64: 406A0780 || [ B1] MPYHLU.M1 A16,A26,A0 0x00800A68: 09F207BF STB.D2T2 B19,*+B15[29191] 0x00800A6C: 002A0700 || MPYDP.M1 A17:A16,A11:A10,A1:A0 0x00800A70: 406A0700 [ B1] MPYDP.M1 A17:A16,A27:A26,A1:A0 0x00800A74: A35A0200 [ A2] MPYI.M1 A16,A22,A6 0x00800A78: 03A20910 B.S1 0x9D1AA8 (PC+1904712 = 0x009d1aa8) 0x00800A7C: 03A20A10 B.S1 0x9D1AB0 (PC+1904720 = 0x009d1ab0) 0x00800A80: 00280184 PLD.D1 *-B10(0),0 0x00800A84: 40680180 [ B1] MPYHSU.M1 A0,A26,A0 0x00800A88: 40280206 [ B1] LDHU.D1T2 *+A10[0],B0 0x00800A8C: 1362000C .word 0x1362000c 0x00800A90: 61620186 [ B2] PLD.D2 *-B24(16),2 0x00800A94: 40680200 [ B1] MPYI.M1 A0,A26,A0 C$RL0: 0x00800A98: 70280185 [!B2] PLD.D1 *-B10(0),0 0x00800A9C: 40680180 || [ B1] MPYHSU.M1 A0,A26,A0 0x00800AA0: 00000000 NOP 0x00800AA4: 1362000C .word 0x1362000c 0x00800AA8: 81620183 [ A1] MPYHSU.M2 B16,B24,B2 C$RL1: 0x00800AAC: 702A0204 || [!B2] LDHU.D1T1 *+A10[16],A0 0x00800AB0: 406A0200 [ B1] MPYI.M1 A16,A26,A0 0x00800AB4: 03620010 B.S1 0x9B1AA0 (PC+1773568 = 0x009b1aa0) 0x00800AB8: 61620188 [ B2] SET.S1 A24,16,1,A2 0x00800ABC: A3580204 [ A2] LDHU.D1T1 *+A22[0],A6 C$RL2: 0x00800AC0: 00E20018 PACK2.L1 A16,A24,A1 0x00800AC4: 80000000 [ A1] NOP 0x00800AC8: 00000000 NOP 0x00800ACC: 00000000 NOP 0x00800AD0: 00000000 NOP 0x00800AD4: 00000000 NOP 0x00800AD8: 00000000 NOP 0x00800ADC: 00000000 NOP _args_main: 0x00800AE0: FFA802FF .word 0xffa802ff 0x00800AE4: FFE902FF || .word 0xffe902ff 0x00800AE8: 902A0285 || [!A1] LDHU.D2T1 *+B10[16],A0 0x00800AEC: 406B0280 || [ B1] MPYHUS.M1 A24,A26,A0

Ron,

You could use the dis6x tool to disassemble the executable file you are trying to load and see if the contents there match what you see in the disassembly window of CCS.  You can also open a memory view in CCS and see if the two contents match as well. If the compiler is generating something unexpected then we can try and figure out why.

Regards, Daniel

Daniel,

I disassembled the .out file with he following result for the first three lines:

00800a60             _c_int00:

00800a60            .text:_c_int00:

00800a60  0783fe2a         MVK.S2                0x7fc,B15

00800a64  0780406a        MVKH.S2             0x800000,B15

00800a68  07bf09f2          AND.D2                -8,B15,B15

 

When viewed in the CCS4.2 disassembler window, the same code looks like this:

00800a60             _c_int00:

00800a60  fe2a0783                 .word                     0xfe2a0783

00800a64  406a0780  ||  [B1]   MPYHLU.M1        A16,A26,A0

00800a68  09F207bf                 STB.D2T2             B19,*+B15[29191]

 

Notice that the hex data is the same, but that, between the two disassemblies, the two words of each instruction are reversed in order. 0783fe2a in the first example becomes fe2a0783 in the second. The assembler seems to be working right, but the code seems to be loading into the DSP incorrectly. When one single step is executed, the processor jumps to 71307A.

Regards,

Ron

Ron,

It would appear that the loading being done by CCS is somehow not happening correctly, and the upper and lower halves of each word are being swapped.  That's very strange and not something that I could explain. But since this is internal memory of the chip, I'm pretty confident that it is not a hardware related issue. I would recommend that this question be moved to the CCS or emulation forums.

I wonder if the XDS100 issue you mentioned in the first post could somehow be related?

Regards, Daniel