Taras-
> Thank you very much for your suggestions. I checked
it again and conclusion remains
> the same - there is clearly a difference in HPI behavior when DSP is stalled
in
> internal reset waiting for DSPINT bit and when it is normally running.
>
> I did as you adviced and tried to read (during stalled state) on the host side
the
> values (EMIF registers) which have just been written via HPI. And result
was
> stunning HPI read in this stalled state is much worse than HPI write. While
HPI
> write fails appr. once on 100 words, the rate of HPI read fails gets 50%. And
what
> is interesting, the errors are very similar to those met previously when I
read in
> fixed mode, that is, one read lag. But then I coped with it by using read
in
> autoincrement mode. In stalled state this "trick" does not work:).
>
> As this point I believe that this is due to some hardware problems. But,
> unfortunately, I cannot check it myself due to lack of special devices needed.
I
> hope my colleagues with assist me with this and I'll let you know
their
> conclusions.
At this point I would focus on verifying HPI signals and timing for HPI read.
There
is no way you should get "half" success. If you are saying you don't have
a digital
scope, then get one -- you can't expect help from the group unless
you're able to
make timing measurements and verify that you're not "guessing" to meet the
data
sheet.
If you have some known DSP memory data, then testing read first is a good idea
as it
simplifies the problem. I don't know whether it's valid to read EMIF
registers --
those are memory-mapped and not all memory-mapped registers are available to HPI
in
the C671x architecture. But if you get correct answers in any case then
it's
probably Ok.
> By the way, how can I slow down the rate of
access?
Put a long delay in between each HPI read.
-Jeff
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Tuesday, February 12, 2008 9:02 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Taras-
>
> > Further investigations showed that indeed there is a difference between
HPI
> > behavior when DSP is in "internal" reset (released from external reset,
but
> > "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT
bit
> is
> > set). Therefore, if I now send DSP appl. code after DSPINT bit is set
then
> > everything is OK appl. code is sent correctly and it is running! However,
a
> > little problem is still annoying because my small bootloader is still sent
during
>
> > DSP internal reset and sometimes some words get corrupted. Nevertheless,
this is
> a
> > solution for a moment.
> > If somebody met such problem in the past or was anyhow concerned with this
please
>
> > be so kind to let me know.
>
> Some suggestions:
>
> 1) Minimize code sent prior to releasing the stall. All that's really
needed is a
> 2-instruction loop that does nothing . Once the chip is running you can load
any
> other code and go from there.
>
> 2) During the stall period treat HPI more carefully. Slow down the rate of
access,
>
> read back each word written, re-try until data is correct.
>
> -Jeff
HPI booting problem
Started by ●February 7, 2008
Reply by ●February 21, 20082008-02-21
Reply by ●February 22, 20082008-02-22
Jeff,
Maybe my sentence about 'colleagues' was unclear and thus misunderstood.
I just meant my colleagues here which are hardware engineers and,
hopefully, did all necessary testing of signal timing. Nevertheless,
I'll ask them to carry out additional, more in-depth testing, especially
focusing on comparison HPI behavior in mentioned DSP states. This could
be a clue.
I have a 2-channel digital scope, but it is not much use of it,
particularly in this case. Because there are too many HPI signals to
check, often simultaneously. Smarter device is needed.
Taras.
_____
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Thursday, February 21, 2008 7:33 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
Thank you very much for your suggestions. I checked it again and
conclusion remains the same - there is clearly a difference in HPI
behavior when DSP is stalled in internal reset waiting for DSPINT bit
and when it is normally running.
I did as you adviced and tried to read (during stalled state) on the
host side the values (EMIF registers) which have just been written via
HPI. And result was stunning - HPI read in this stalled state is much
worse than HPI write. While HPI write fails appr. once on 100 words, the
rate of HPI read fails gets 50%. And what is interesting, the errors are
very similar to those met previously when I read in fixed mode, that is,
one read lag. But then I coped with it by using read in autoincrement
mode. In stalled state this "trick" does not work:).
As this point I believe that this is due to some hardware problems. But,
unfortunately, I cannot check it myself due to lack of special devices
needed. I hope my colleagues with assist me with this and I'll let you
know their conclusions.
At this point I would focus on verifying HPI signals and timing for HPI
read. There is no way you should get "half" success. If you are saying
you don't have a digital scope, then get one -- you can't expect help
from the group unless you're able to make timing measurements and verify
that you're not "guessing" to meet the data sheet.
If you have some known DSP memory data, then testing read first is a
good idea as it simplifies the problem. I don't know whether it's
valid to read EMIF registers -- those are memory-mapped and not all
memory-mapped registers are available to HPI in the C671x architecture.
But if you get correct answers in any case then it's probably Ok.
By the way, how can I slow down the rate of access?
Put a long delay in between each HPI read.
-Jeff
-----Original Message-----
From: Jeff Brower [ mailto:j...@signalogic.com]
Sent: Tuesday, February 12, 2008 9:02 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
> Further investigations showed that indeed there is a
difference between HPI
> behavior when DSP is in "internal" reset (released from
external reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running
(after DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit
is set then
> everything is OK - appl. code is sent correctly and it is
running! However, a
> little problem is still annoying because my small bootloader
is still sent during
> DSP internal reset and sometimes some words get corrupted.
Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow
concerned with this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's
really needed is a
2-instruction loop that does nothing . Once the chip is running
you can load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down
the rate of access,
read back each word written, re-try until data is correct.
-Jeff
Maybe my sentence about 'colleagues' was unclear and thus misunderstood.
I just meant my colleagues here which are hardware engineers and,
hopefully, did all necessary testing of signal timing. Nevertheless,
I'll ask them to carry out additional, more in-depth testing, especially
focusing on comparison HPI behavior in mentioned DSP states. This could
be a clue.
I have a 2-channel digital scope, but it is not much use of it,
particularly in this case. Because there are too many HPI signals to
check, often simultaneously. Smarter device is needed.
Taras.
_____
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Thursday, February 21, 2008 7:33 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
Thank you very much for your suggestions. I checked it again and
conclusion remains the same - there is clearly a difference in HPI
behavior when DSP is stalled in internal reset waiting for DSPINT bit
and when it is normally running.
I did as you adviced and tried to read (during stalled state) on the
host side the values (EMIF registers) which have just been written via
HPI. And result was stunning - HPI read in this stalled state is much
worse than HPI write. While HPI write fails appr. once on 100 words, the
rate of HPI read fails gets 50%. And what is interesting, the errors are
very similar to those met previously when I read in fixed mode, that is,
one read lag. But then I coped with it by using read in autoincrement
mode. In stalled state this "trick" does not work:).
As this point I believe that this is due to some hardware problems. But,
unfortunately, I cannot check it myself due to lack of special devices
needed. I hope my colleagues with assist me with this and I'll let you
know their conclusions.
At this point I would focus on verifying HPI signals and timing for HPI
read. There is no way you should get "half" success. If you are saying
you don't have a digital scope, then get one -- you can't expect help
from the group unless you're able to make timing measurements and verify
that you're not "guessing" to meet the data sheet.
If you have some known DSP memory data, then testing read first is a
good idea as it simplifies the problem. I don't know whether it's
valid to read EMIF registers -- those are memory-mapped and not all
memory-mapped registers are available to HPI in the C671x architecture.
But if you get correct answers in any case then it's probably Ok.
By the way, how can I slow down the rate of access?
Put a long delay in between each HPI read.
-Jeff
-----Original Message-----
From: Jeff Brower [ mailto:j...@signalogic.com]
Sent: Tuesday, February 12, 2008 9:02 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
> Further investigations showed that indeed there is a
difference between HPI
> behavior when DSP is in "internal" reset (released from
external reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running
(after DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit
is set then
> everything is OK - appl. code is sent correctly and it is
running! However, a
> little problem is still annoying because my small bootloader
is still sent during
> DSP internal reset and sometimes some words get corrupted.
Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow
concerned with this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's
really needed is a
2-instruction loop that does nothing . Once the chip is running
you can load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down
the rate of access,
read back each word written, re-try until data is correct.
-Jeff
Reply by ●February 22, 20082008-02-22
Taras-
> Maybe my sentence about colleagues was unclear and thus misunderstood. I just
> meant my colleagues here which are hardware engineers and, hopefully, did all
> necessary testing of signal timing. Nevertheless, Ill ask them to carry out
> additional, more in-depth testing, especially focusing on comparison HPI behavior
> in mentioned DSP states. This could be a clue.
>
> I have a 2-channel digital scope, but it is not much use of it, particularly in
> this case. Because there are too many HPI signals to check, often simultaneously.
> Smarter device is needed.
>
Well if it were me I wouldn't wait for the 'colleagues' since they've stuck you with
the problem and they're not on the group asking questions (maybe they should be). A
2-chan scope is fine. First, make sure /HCS is always low (i.e. tied low). No need
to move /HCS around in your first stage of getting things to work. Second, use /HDS
on one trace to trigger and look at some other signals. First make sure HR/W is
stable prior to onset of /HDS -- if not that could cause the error your seeing (the
device thinks it's a write but you think its a read, so HPI increments but data is
messed up). Third make sure HRDY is always indicating the device is ready (should
be, since you're not running any code or using internal DMA channels). Then make
sure /HDS itself meets data sheet specs for setup time, hold-time, duration.
Note, when I say /HDS I mean the combined internal strobe -- typically HDS1 tied high
and /HDS2 used as the external strobe.
-Jeff
> ------------
> From: Jeff Brower [mailto:j...@signalogic.com]
>
> Sent: Thursday, February 21, 2008 7:33 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Taras-
>
> Thank you very much for your suggestions. I checked it again and conclusion remains
> the same - there is clearly a difference in HPI behavior when DSP is stalled in
> internal reset waiting for DSPINT bit and when it is normally running.
>
> I did as you adviced and tried to read (during stalled state) on the host side the
> values (EMIF registers) which have just been written via HPI. And result was
> stunning HPI read in this stalled state is much worse than HPI write. While HPI
> write fails appr. once on 100 words, the rate of HPI read fails gets 50%. And what
> is interesting, the errors are very similar to those met previously when I read in
> fixed mode, that is, one read lag. But then I coped with it by using read in
> autoincrement mode. In stalled state this "trick" does not work:).
>
> As this point I believe that this is due to some hardware problems. But,
> unfortunately, I cannot check it myself due to lack of special devices needed. I
> hope my colleagues with assist me with this and I'll let you know their
> conclusions.
> At this point I would focus on verifying HPI signals and timing for HPI read.
> There is no way you should get "half" success. If you are saying you don't have a
> digital scope, then get one -- you can't expect help from the group unless you're
> able to make timing measurements and verify that you're not "guessing" to meet the
> data sheet.
>
> If you have some known DSP memory data, then testing read first is a good idea as
> it simplifies the problem. I don't know whether it's valid to read EMIF registers
> -- those are memory-mapped and not all memory-mapped registers are available to HPI
> in the C671x architecture. But if you get correct answers in any case then it's
> probably Ok.
>
>> By the way, how can I slow down the rate of access?
>> Put a long delay in between each HPI read.
>
> -Jeff
>
>> -----Original Message-----
>>
>> From: Jeff Brower [mailto:j...@signalogic.com]
>> Sent: Tuesday, February 12, 2008 9:02 PM
>> To: Kurnytskyi Taras
>> Cc: c...
>> Subject: Re: [c6x] HPI booting problem
>>
>> Taras-
>>
>> > Further investigations showed that indeed there is a difference between HPI
>> > behavior when DSP is in "internal" reset (released from external reset, but
>> > "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit
>> is
>> > set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
>> > everything is OK appl. code is sent correctly and it is running! However, a
>> > little problem is still annoying because my small bootloader is still sent
>> during
>> > DSP internal reset and sometimes some words get corrupted. Nevertheless, this
>> is a
>> > solution for a moment.
>> > If somebody met such problem in the past or was anyhow concerned with this
>> please
>> > be so kind to let me know.
>>
>> Some suggestions:
>>
>> 1) Minimize code sent prior to releasing the stall. All that's really needed is
>> a
>> 2-instruction loop that does nothing . Once the chip is running you can load any
>>
>> other code and go from there.
>>
>> 2) During the stall period treat HPI more carefully. Slow down the rate of
>> access,
>> read back each word written, re-try until data is correct.
>>
>> -Jeff
>
> Maybe my sentence about colleagues was unclear and thus misunderstood. I just
> meant my colleagues here which are hardware engineers and, hopefully, did all
> necessary testing of signal timing. Nevertheless, Ill ask them to carry out
> additional, more in-depth testing, especially focusing on comparison HPI behavior
> in mentioned DSP states. This could be a clue.
>
> I have a 2-channel digital scope, but it is not much use of it, particularly in
> this case. Because there are too many HPI signals to check, often simultaneously.
> Smarter device is needed.
>
Well if it were me I wouldn't wait for the 'colleagues' since they've stuck you with
the problem and they're not on the group asking questions (maybe they should be). A
2-chan scope is fine. First, make sure /HCS is always low (i.e. tied low). No need
to move /HCS around in your first stage of getting things to work. Second, use /HDS
on one trace to trigger and look at some other signals. First make sure HR/W is
stable prior to onset of /HDS -- if not that could cause the error your seeing (the
device thinks it's a write but you think its a read, so HPI increments but data is
messed up). Third make sure HRDY is always indicating the device is ready (should
be, since you're not running any code or using internal DMA channels). Then make
sure /HDS itself meets data sheet specs for setup time, hold-time, duration.
Note, when I say /HDS I mean the combined internal strobe -- typically HDS1 tied high
and /HDS2 used as the external strobe.
-Jeff
> ------------
> From: Jeff Brower [mailto:j...@signalogic.com]
>
> Sent: Thursday, February 21, 2008 7:33 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Taras-
>
> Thank you very much for your suggestions. I checked it again and conclusion remains
> the same - there is clearly a difference in HPI behavior when DSP is stalled in
> internal reset waiting for DSPINT bit and when it is normally running.
>
> I did as you adviced and tried to read (during stalled state) on the host side the
> values (EMIF registers) which have just been written via HPI. And result was
> stunning HPI read in this stalled state is much worse than HPI write. While HPI
> write fails appr. once on 100 words, the rate of HPI read fails gets 50%. And what
> is interesting, the errors are very similar to those met previously when I read in
> fixed mode, that is, one read lag. But then I coped with it by using read in
> autoincrement mode. In stalled state this "trick" does not work:).
>
> As this point I believe that this is due to some hardware problems. But,
> unfortunately, I cannot check it myself due to lack of special devices needed. I
> hope my colleagues with assist me with this and I'll let you know their
> conclusions.
> At this point I would focus on verifying HPI signals and timing for HPI read.
> There is no way you should get "half" success. If you are saying you don't have a
> digital scope, then get one -- you can't expect help from the group unless you're
> able to make timing measurements and verify that you're not "guessing" to meet the
> data sheet.
>
> If you have some known DSP memory data, then testing read first is a good idea as
> it simplifies the problem. I don't know whether it's valid to read EMIF registers
> -- those are memory-mapped and not all memory-mapped registers are available to HPI
> in the C671x architecture. But if you get correct answers in any case then it's
> probably Ok.
>
>> By the way, how can I slow down the rate of access?
>> Put a long delay in between each HPI read.
>
> -Jeff
>
>> -----Original Message-----
>>
>> From: Jeff Brower [mailto:j...@signalogic.com]
>> Sent: Tuesday, February 12, 2008 9:02 PM
>> To: Kurnytskyi Taras
>> Cc: c...
>> Subject: Re: [c6x] HPI booting problem
>>
>> Taras-
>>
>> > Further investigations showed that indeed there is a difference between HPI
>> > behavior when DSP is in "internal" reset (released from external reset, but
>> > "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit
>> is
>> > set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
>> > everything is OK appl. code is sent correctly and it is running! However, a
>> > little problem is still annoying because my small bootloader is still sent
>> during
>> > DSP internal reset and sometimes some words get corrupted. Nevertheless, this
>> is a
>> > solution for a moment.
>> > If somebody met such problem in the past or was anyhow concerned with this
>> please
>> > be so kind to let me know.
>>
>> Some suggestions:
>>
>> 1) Minimize code sent prior to releasing the stall. All that's really needed is
>> a
>> 2-instruction loop that does nothing . Once the chip is running you can load any
>>
>> other code and go from there.
>>
>> 2) During the stall period treat HPI more carefully. Slow down the rate of
>> access,
>> read back each word written, re-try until data is correct.
>>
>> -Jeff
>
Reply by ●February 22, 20082008-02-22
Hi ,
I updated the memory map in DSP/BIOS , But when I build the values are
not reflected in the map file. the map is taking the value from the .cmd
file which is generated by the CCS, and the .cmd file in turns gets the
value from the .cdb file. But when i checked the .cdb file , the value
which were being displayed in the .map file were not there. can you
explain me how to update the DSP/Bios so it will rflect it in .map file.
~kurrinchi
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
I updated the memory map in DSP/BIOS , But when I build the values are
not reflected in the map file. the map is taking the value from the .cmd
file which is generated by the CCS, and the .cmd file in turns gets the
value from the .cdb file. But when i checked the .cdb file , the value
which were being displayed in the .map file were not there. can you
explain me how to update the DSP/Bios so it will rflect it in .map file.
~kurrinchi
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●February 23, 20082008-02-23
kurrinchi,
On Fri, Feb 22, 2008 at 12:45 PM, kurrinchi kumar balakrishnan
wrote:
> Hi ,
>
> I updated the memory map in DSP/BIOS , But when I build the values are
> not reflected in the map file. the map is taking the value from the .cmd
> file which is generated by the CCS, and the .cmd file in turns gets the
> value from the .cdb file. But when i checked the .cdb file , the value
> which were being displayed in the .map file were not there. can you
> explain me how to update the DSP/Bios so it will rflect it in .map file.
You just need to rerun the bios configuration to generate updates. If
you have a GUI config, just open the CDB file in CCS and save it.
mikedunn
>
> ~kurrinchi
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
On Fri, Feb 22, 2008 at 12:45 PM, kurrinchi kumar balakrishnan
wrote:
> Hi ,
>
> I updated the memory map in DSP/BIOS , But when I build the values are
> not reflected in the map file. the map is taking the value from the .cmd
> file which is generated by the CCS, and the .cmd file in turns gets the
> value from the .cdb file. But when i checked the .cdb file , the value
> which were being displayed in the .map file were not there. can you
> explain me how to update the DSP/Bios so it will rflect it in .map file.
You just need to rerun the bios configuration to generate updates. If
you have a GUI config, just open the CDB file in CCS and save it.
mikedunn
>
> ~kurrinchi
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
