Thanks for the response.
The vector table appears to be programmed in correctly, with the HWI_RESET
vector looking like this:
00000000 000D002A MVK.S2 0x1a00,B0
00000004 0040E2EA MVKH.S2 0x81c50000,B0
00000008 00000362 B.S2 B0
0000000C 0000A35A MVK.L2 0,B0
00000010 020003A2 MVC.S2 B0,IER
00000014 00000000 NOP
00000018 00000000 NOP
0000001C 00000000 NOP
Based upon my (limited) knowledge of the DM642 assembly language, this sets the
B0 register to the address 0x81c51a00 and then performs a branch to this
address. This makes sense as 0x81c51a00 is the location of c_init00.
What I am not sure about is what the two move instructions after the branch are
for, and how they are executed after a non-conditional branch (I am assuming
that this is something clever to do with the way the CPU fetches and executes
instructions?).
No other interuppts are used.
I don't think the processor is even getting to the RESET vector, but I am
not sure how to prove it. I know that if I load the code from the Host via the
HPI, and then connect CCS via the Emulator (with no project open and without
re-loading the code), I can hit run and the code executes correctly.
It is worth noting that at the point where I connect to the target, the
Programme Counter already seems to be pre-loaded with 0x81C51A00 (and B0 is
00000000), which suggests that CCS is picking up the address of c_init00 from
somewhere (presumably the vector table as the project is not open) and executing
directly from there.
Any further thoughts or suggestions would be much appreciated.
Regards,
Paul.
>Hi,
>
>I saw this old thread on a forum and wanted to ask you if you resolved the
problem you were having with the code starting to execute?
>
>I have a similar problem myself with the DM642, except that I am using the HPI
interface to load my software on a bespoke PCB design.
>
>The steps I follow are:
>1. Take the processor out of reset and into host boot mode.
>2. Configure the EMIF.
>3. Load the code via the HPI (and verify it is correct).
>4. Assert the DSPINT bit in the HPIC register.
>
>Everything seems to work fine, but the code does not start executing. I know
the hardware is OK because I can run the code on my emulator. I can also use
the emulator to view the memory space, so I know the code is programmed and the
DSPINT bit is being set.
>
>Any help would be appreciated,
>
>Many thanks,
>
>Paul.
>hello
>> is it possible to burn your aplication/code by a pci when the card is
>> in the computer? or the pci is only for send/recieve data?
>>
>> thanks
>> amitai
>
>_____________________________________
_____________________________________
Re: working on dm642 with pci
Started by ●January 28, 2009
Reply by ●January 28, 20092009-01-28
Paul,
On Wed, Jan 28, 2009 at 6:38 AM, wrote:
> Thanks for the response.
>
> The vector table appears to be programmed in correctly, with the HWI_RESET
> vector looking like this:
>
> 00000000 000D002A MVK.S2 0x1a00,B0
> 00000004 0040E2EA MVKH.S2 0x81c50000,B0
> 00000008 00000362 B.S2 B0
> 0000000C 0000A35A MVK.L2 0,B0
> 00000010 020003A2 MVC.S2 B0,IER
> 00000014 00000000 NOP
> 00000018 00000000 NOP
> 0000001C 00000000 NOP
>
> Based upon my (limited) knowledge of the DM642 assembly language, this sets
> the B0 register to the address 0x81c51a00 and then performs a branch to this
> address. This makes sense as 0x81c51a00 is the location of c_init00.
>
> What I am not sure about is what the two move instructions after the branch
> are for, and how they are executed after a non-conditional branch (I am
> assuming that this is something clever to do with the way the CPU fetches
> and executes instructions?).
Multicycle instructions have 'delay slots' during which code is
executed 'while the multicycle instruction is in progress'. The 2
moves will be complete by the time that the 'branch occurs'.
The 2 instructions 'clear B0' and copy B0 to the IER [interrupt enable
register].
>
> No other interuppts are used.
>
> I don't think the processor is even getting to the RESET vector, but I am
> not sure how to prove it. I know that if I load the code from the Host via
> the HPI, and then connect CCS via the Emulator (with no project open and
> without re-loading the code), I can hit run and the code executes correctly.
> It is worth noting that at the point where I connect to the target, the
> Programme Counter already seems to be pre-loaded with 0x81C51A00 (and B0 is
> 00000000), which suggests that CCS is picking up the address of c_init00
> from somewhere (presumably the vector table as the project is not open) and
> executing directly from there.
You are on the right track.
To start with, simplify your testcase to run only in internal memory.
Once you get it working, move the same code to external memory. This
will reduce the chances of working on multiple problems. The
scenarios below assume a simple testcase in internal memory. As you
probably know, you cannot use normal 'printf's for troubleshooting
this problem. Your testcase should execute to build a pattern in
memory or registers [or some LEDs, if available] to verify success.
Testcase A:
1. Bring up CCS, connect to target
2. Load any working program
3. Select 'Run free' [not run]
4. Disconnect [in CCS] from the target
5. Reset target from host
6. Load program from host
7. Connect CCS. Verify target is halted
8. Observe PC. If PC!=0, set it to zero
9. Run loaded program
Testcase B:
The results should match when you
1. Bring up CCS, connect to target
2. Perform Cpu Reset
3. Load test program from CCS.
4. Run
Testcase C: [normal use case]
1. Reset target from host
2. Load program from host
3. issue DSPINT from host
Testcase results: A == B != C
It would appear to be a problem related to DSPINT
Testcase results: A != B
It would appear to be a program load problem [or you are trying to use printf]
mikedunn
>
> Any further thoughts or suggestions would be much appreciated.
>
> Regards,
>
> Paul.
>
>>Hi,
>>
>>I saw this old thread on a forum and wanted to ask you if you resolved the
>> problem you were having with the code starting to execute?
>>
>>I have a similar problem myself with the DM642, except that I am using the
>> HPI interface to load my software on a bespoke PCB design.
>>
>>The steps I follow are:
>>1. Take the processor out of reset and into host boot mode.
>>2. Configure the EMIF.
>>3. Load the code via the HPI (and verify it is correct).
>>4. Assert the DSPINT bit in the HPIC register.
>>
>>Everything seems to work fine, but the code does not start executing. I
>> know the hardware is OK because I can run the code on my emulator. I can
>> also use the emulator to view the memory space, so I know the code is
>> programmed and the DSPINT bit is being set.
>>
>>Any help would be appreciated,
>>
>>Many thanks,
>>
>>Paul.
>>hello
>>> is it possible to burn your aplication/code by a pci when the card is
>>> in the computer? or the pci is only for send/recieve data?
>>>
>>> thanks
>>> amitai
>>
>>_____________________________________
>>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
_____________________________________
On Wed, Jan 28, 2009 at 6:38 AM, wrote:
> Thanks for the response.
>
> The vector table appears to be programmed in correctly, with the HWI_RESET
> vector looking like this:
>
> 00000000 000D002A MVK.S2 0x1a00,B0
> 00000004 0040E2EA MVKH.S2 0x81c50000,B0
> 00000008 00000362 B.S2 B0
> 0000000C 0000A35A MVK.L2 0,B0
> 00000010 020003A2 MVC.S2 B0,IER
> 00000014 00000000 NOP
> 00000018 00000000 NOP
> 0000001C 00000000 NOP
>
> Based upon my (limited) knowledge of the DM642 assembly language, this sets
> the B0 register to the address 0x81c51a00 and then performs a branch to this
> address. This makes sense as 0x81c51a00 is the location of c_init00.
>
> What I am not sure about is what the two move instructions after the branch
> are for, and how they are executed after a non-conditional branch (I am
> assuming that this is something clever to do with the way the CPU fetches
> and executes instructions?).
Multicycle instructions have 'delay slots' during which code is
executed 'while the multicycle instruction is in progress'. The 2
moves will be complete by the time that the 'branch occurs'.
The 2 instructions 'clear B0' and copy B0 to the IER [interrupt enable
register].
>
> No other interuppts are used.
>
> I don't think the processor is even getting to the RESET vector, but I am
> not sure how to prove it. I know that if I load the code from the Host via
> the HPI, and then connect CCS via the Emulator (with no project open and
> without re-loading the code), I can hit run and the code executes correctly.
> It is worth noting that at the point where I connect to the target, the
> Programme Counter already seems to be pre-loaded with 0x81C51A00 (and B0 is
> 00000000), which suggests that CCS is picking up the address of c_init00
> from somewhere (presumably the vector table as the project is not open) and
> executing directly from there.
You are on the right track.
To start with, simplify your testcase to run only in internal memory.
Once you get it working, move the same code to external memory. This
will reduce the chances of working on multiple problems. The
scenarios below assume a simple testcase in internal memory. As you
probably know, you cannot use normal 'printf's for troubleshooting
this problem. Your testcase should execute to build a pattern in
memory or registers [or some LEDs, if available] to verify success.
Testcase A:
1. Bring up CCS, connect to target
2. Load any working program
3. Select 'Run free' [not run]
4. Disconnect [in CCS] from the target
5. Reset target from host
6. Load program from host
7. Connect CCS. Verify target is halted
8. Observe PC. If PC!=0, set it to zero
9. Run loaded program
Testcase B:
The results should match when you
1. Bring up CCS, connect to target
2. Perform Cpu Reset
3. Load test program from CCS.
4. Run
Testcase C: [normal use case]
1. Reset target from host
2. Load program from host
3. issue DSPINT from host
Testcase results: A == B != C
It would appear to be a problem related to DSPINT
Testcase results: A != B
It would appear to be a program load problem [or you are trying to use printf]
mikedunn
>
> Any further thoughts or suggestions would be much appreciated.
>
> Regards,
>
> Paul.
>
>>Hi,
>>
>>I saw this old thread on a forum and wanted to ask you if you resolved the
>> problem you were having with the code starting to execute?
>>
>>I have a similar problem myself with the DM642, except that I am using the
>> HPI interface to load my software on a bespoke PCB design.
>>
>>The steps I follow are:
>>1. Take the processor out of reset and into host boot mode.
>>2. Configure the EMIF.
>>3. Load the code via the HPI (and verify it is correct).
>>4. Assert the DSPINT bit in the HPIC register.
>>
>>Everything seems to work fine, but the code does not start executing. I
>> know the hardware is OK because I can run the code on my emulator. I can
>> also use the emulator to view the memory space, so I know the code is
>> programmed and the DSPINT bit is being set.
>>
>>Any help would be appreciated,
>>
>>Many thanks,
>>
>>Paul.
>>hello
>>> is it possible to burn your aplication/code by a pci when the card is
>>> in the computer? or the pci is only for send/recieve data?
>>>
>>> thanks
>>> amitai
>>
>>_____________________________________
>>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
_____________________________________
