Dinesh-
> As you can see the address is being loaded to B1 but
the branch is
> from B3 which is incorrect.
We had a similar problem with EVM DM642 board code on a previous project
in 2003. We modified (hacked) the code after downloading to DSP memory,
prior to run, changing the instructions as needed.
That works Ok in a PC environment, but not for stand-alone Flash boot
operation.
For a long-term fix, maybe you can try a newer version of CCS, or maybe
there are patches available for DM642 CSL or DSP/BIOS? It would not be
the first time that TI provided patches for DM642.
-Jeff
> I'm trying to build a program to verify the
operation of a DM642 video
> port. Our custom board has the SDRAM in CE2 and VP2 as the capture
> port. When I modify the existing BIOS files to reflect these changes
> and build the project, the program stalls in the BIOS intialization
> routine.
>
> I know where the problem is but I don't know how to get around it.
> The following are the first few instructions from _BIOS_init of the
> jpeg_loopback.s62 file (Generated file).
>
> _BIOS_init:
> GBL_preamble
> STW.D2T2 B1, *SP--[0x2]
> GBL_init
> MVK.S2 0x5680,B1
> MVKH.S2 0xA0E30000,B1
> B.S2 B3
>
> As you can see the address is being loaded to B1 but the branch is
> from B3 which is incorrect. If you want to see the correct operation,
> you can load the jpeg_loopback program, set a breakpoint at the
> GBL_preamble of jpeg_loopback.s62 file and go through the assembly
> code. In the correct version, the address is loaded to B3 and the
> branch is from B3 also.
>
> The only changes I am making to the original BIOS file are
> 1. location SDRAM base to A0000000 (CE2)
> 2. Remove the Display port and move capture video port to VP2.
>
> What changes to a BIOS file can affect the code generation process?
>
> If anyone has experience with video ports and know of another or
> easier way to test for video port functionality, please let me know.
> I've been stuck on this problem for a few days :(
>
> Thanks,
> Dinesh