AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

Hello all,

I'm working on the project whose objectives are

1) to establish communication via HPI between Atmel's At91M40008 host
processor and C6711D and 

2) to boot DSP processor via HPI.

I've already tested communication and it works satisfactory but not
ideally. Not ideally because I have to read only in autoincrement mode
since read in fixed mode is unstable and thus incorrect in general. I
looked through errata documentation from TI and found that bug with HPI
read in fixed mode is known exception to C6711 functioning. The
workaround they offer is quite simple, namely, they advise to use HPI
read in autoincrement mode only. This helped, but still I have to read
the first address twice to get correct values.

HPI write was successful is both modes. It should be noted, however,
that packets exchanged between processors were rather small - not more
than 40 bytes.

Then I proceeded to testing booting via HPI. I write via HPI small DSP
pseudobootloader first (it configures PLL and McBSP) and then DSP
application itself. Then release DSP from reset. For now, I have the
following results - DSP application starts up correctly appr. 1 time out
of 10 attempts. The reason of unsuccessful attempts is that some words
sent by HPI write are incorrect. DSP bootloader size is appr. 2,5KB;
therefore just a few words out of appr. 600 are invalid. And it repeats
permanently. But why??? Why at some arbitrary moment HPI write is
incorrect? I believe I would be more optimistic if HPI write did not
work at all - in that case I would be sure that I missed something in
HPI setting, etc. But this random write fails disappoints me much more
because I have now idea why this happens. Maybe, some sort of hardware
problems?

Will be very grateful for any comments.

Thank you in advance.

With best regards,

MITA-TEKNIK

Taras Kournytskyi

Software developer

Contact details:

<mailto:t...@mitaua.dk> tku <mailto:t...@mitaua.dk> @mitaua.dk
Direct phone.:  +380(32)2420435

Company details:

Mita-Teknik Ltd.

Kulparkivska 222a

79071 Lviv

Ukraine

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kurnytskyi-
> I’m working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel’s At91M40008 host
processor and
> C6711D and
>
> 2) to boot DSP processor via HPI.
> I’ve already tested communication and it works satisfactory but not
ideally. Not
> ideally because I have to read only in autoincrement mode since read in
fixed mode
> is unstable and thus incorrect in general. I looked through errata
documentation
> from TI and found that bug with HPI read in fixed mode is known exception
to C6711
> functioning. The workaround they offer is quite simple, namely, they advise
to use
> HPI read in autoincrement mode only. This helped, but still I have to read
the
> first address twice to get correct values.
>
> HPI write was successful is both modes. It should be noted, however, that
packets
> exchanged between processors were rather small – not more than 40 bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
application
> itself. Then release DSP from reset. For now, I have the following results
– DSP
> application starts up correctly appr. 1 time out of 10 attempts. The reason
of
> unsuccessful attempts is that some words sent by HPI write are incorrect.
DSP
> bootloader size is appr. 2,5KB; therefore just a few words out of appr. 600
are
> invalid. And it repeats permanently. But why??? Why at some arbitrary
moment HPI
> write is incorrect? I believe I would be more optimistic if HPI write did
not work
> at all – in that case I would be sure that I missed something in HPI
setting, etc.
> But this random write fails disappoints me much more because I have now
idea why
> this happens. Maybe, some sort of hardware problems?

My suggestion is to back up a step and continue with HPI testing.  You should be
able
to do reliable "stress test" of HPI, using random combinations of
read, write,
different addresses, tests that run overnight, etc.

In this way you will find the problem... maybe your Atmel code does not handle
HRDY
or HDS correctly, etc.  Or maybe there is still something in the errata that you
have
not implemented or understood completely.  Sometimes the errata can be an
exercise in
"reading between the lines" to understand what is really the problem
-- for example
something that TI does not want to admit openly.

Then move on to bootloader.

-Jeff

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Jeff,

Thank you for advice.

Regarding the "stress test", I've not carried out it yet, however
tests
with randomly changing write/read addresses were successfully passed.
Moreover, if I write the same bootloader code (just to test HPI write)
in SDRAM address when DSP application is running (booted from its flash)
then everything is OK - no HPI write fails. Besides, I've also noticed
that HPI reads fail during HPI booting. Therefore, it can be stated with
a high probability that something different happens during HPI write
when DSP is in reset and when it is running.

Regards,

Taras

  _____  

From: Jeff Brower [mailto:j...@signalogic.com] 
Sent: Thursday, February 07, 2008 11:38 PM
To: Kurnytskyi Taras
Cc: c...@yahoogroups.com
Subject: Re: [c6x] HPI booting problem

Kurnytskyi-

I'm working on the project whose objectives are

1) to establish communication via HPI between Atmel's At91M40008 host
processor and C6711D and 

2) to boot DSP processor via HPI.

I've already tested communication and it works satisfactory but not
ideally. Not ideally because I have to read only in autoincrement mode
since read in fixed mode is unstable and thus incorrect in general. I
looked through errata documentation from TI and found that bug with HPI
read in fixed mode is known exception to C6711 functioning. The
workaround they offer is quite simple, namely, they advise to use HPI
read in autoincrement mode only. This helped, but still I have to read
the first address twice to get correct values. 

HPI write was successful is both modes. It should be noted, however,
that packets exchanged between processors were rather small - not more
than 40 bytes. 

Then I proceeded to testing booting via HPI. I write via HPI small DSP
pseudobootloader first (it configures PLL and McBSP) and then DSP
application itself. Then release DSP from reset. For now, I have the
following results - DSP application starts up correctly appr. 1 time out
of 10 attempts. The reason of unsuccessful attempts is that some words
sent by HPI write are incorrect. DSP bootloader size is appr. 2,5KB;
therefore just a few words out of appr. 600 are invalid. And it repeats
permanently. But why??? Why at some arbitrary moment HPI write is
incorrect? I believe I would be more optimistic if HPI write did not
work at all - in that case I would be sure that I missed something in
HPI setting, etc. But this random write fails disappoints me much more
because I have now idea why this happens. Maybe, some sort of hardware
problems?

My suggestion is to back up a step and continue with HPI testing.  You
should be able to do reliable "stress test" of HPI, using random
combinations of read, write, different addresses, tests that run
overnight, etc. 

In this way you will find the problem... maybe your Atmel code does not
handle HRDY or HDS correctly, etc.  Or maybe there is still something in
the errata that you have not implemented or understood completely.
Sometimes the errata can be an exercise in "reading between the
lines"
to understand what is really the problem -- for example something that
TI does not want to admit openly. 

Then move on to bootloader. 

-Jeff 
  

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Taras,

On Feb 8, 2008 10:21 AM, Kurnytskyi Taras <t...@mitaua.dk> wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet, however
tests w=
ith
> randomly changing write/read addresses were successfully passed. Moreover=
,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK =96 no HPI write fails. Besides, I've also noticed that =
HPI
> reads fail during HPI booting.

I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.

>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP is=
 in
> reset and when it is running.

When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??

mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
>  Sent: Thursday, February 07, 2008 11:38 PM
>  To: Kurnytskyi Taras
>  Cc: c...@yahoogroups.com
>  Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not ideal=
ly.
> Not ideally because I have to read only in autoincrement mode since read =
in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed mo=
de
> is known exception to C6711 functioning. The workaround they offer is qui=
te
> simple, namely, they advise to use HPI read in autoincrement mode only. T=
his
> helped, but still I have to read the first address twice to get correct
> values.
>
> HPI write was successful is both modes. It should be noted, however, that
> packets exchanged between processors were rather small =96 not more than =
40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results =96 DSP application starts up correctly appr. 1 time ou=
t of
> 10 attempts. The reason of unsuccessful attempts is that some words sent =
by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore ju=
st
> a few words out of appr. 600 are invalid. And it repeats permanently. But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe I
> would be more optimistic if HPI write did not work at all =96 in that cas=
e I
> would be sure that I missed something in HPI setting, etc. But this rando=
m
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
>  My suggestion is to back up a step and continue with HPI testing.  You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run overnigh=
t,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does not
> handle HRDY or HDS correctly, etc.  Or maybe there is still something in =
the
> errata that you have not implemented or understood completely.  Sometimes
> the errata can be an exercise in "reading between the lines" to
understan=
d
> what is really the problem -- for example something that TI does not want=
 to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>=20=20=20=20

--=20
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Tr=
anscoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm64=
67

=20

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Mike-

> On Feb 8, 2008 10:21 AM, Kurnytskyi Taras <t...@mitaua.dk> wrote:
> > Hi Jeff,
> > Thank you for advice.
> >
> > Regarding the "stress test", I've not carried out it yet,
however tests with
> > randomly changing write/read addresses were successfully passed.
Moreover,
> > if I write the same bootloader code (just to test HPI write) in SDRAM
> > address when DSP application is running (booted from its flash) then
> > everything is OK – no HPI write fails. Besides, I've also noticed
that HPI
> > reads fail during HPI booting.
> 
> I believe that 'HPI boot mode' is write only [wrt the host] until you
> issue DSPINT.

The C6711D data sheet indicates the host can read/write DSP mem while the CPU
is
"stalled" (before DSPINT bit is set).

-Jeff

> >Therefore, it can be stated with a high
> > probability that something different happens during HPI write when DSP
is in
> > reset and when it is running.
> 
> When you say that 'the DSP is in reset', are you referring to the
> state during HPI boot or are you applying an external reset during HPI
> boot??
> 
> mikedunn
> >
> > Regards,
> > Taras
> > ______________________________
> >
> >
> > From: Jeff Brower [mailto:j...@signalogic.com]
> >  Sent: Thursday, February 07, 2008 11:38 PM
> >  To: Kurnytskyi Taras
> >  Cc: c...@yahoogroups.com
> >  Subject: Re: [c6x] HPI booting problem
> >
> > Kurnytskyi-
> >
> > I'm working on the project whose objectives are
> >
> > 1) to establish communication via HPI between Atmel's At91M40008 host
> > processor and C6711D and
> >
> > 2) to boot DSP processor via HPI.
> >
> > I've already tested communication and it works satisfactory but not
ideally.
> > Not ideally because I have to read only in autoincrement mode since
read in
> > fixed mode is unstable and thus incorrect in general. I looked
through
> > errata documentation from TI and found that bug with HPI read in fixed
mode
> > is known exception to C6711 functioning. The workaround they offer is
quite
> > simple, namely, they advise to use HPI read in autoincrement mode
only. This
> > helped, but still I have to read the first address twice to get
correct
> > values.
> >
> > HPI write was successful is both modes. It should be noted, however,
that
> > packets exchanged between processors were rather small – not more
than 40
> > bytes.
> >
> > Then I proceeded to testing booting via HPI. I write via HPI small
DSP
> > pseudobootloader first (it configures PLL and McBSP) and then DSP
> > application itself. Then release DSP from reset. For now, I have the
> > following results – DSP application starts up correctly appr. 1 time
out of
> > 10 attempts. The reason of unsuccessful attempts is that some words
sent by
> > HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore
just
> > a few words out of appr. 600 are invalid. And it repeats permanently.
But
> > why??? Why at some arbitrary moment HPI write is incorrect? I believe
I
> > would be more optimistic if HPI write did not work at all – in that
case I
> > would be sure that I missed something in HPI setting, etc. But this
random
> > write fails disappoints me much more because I have now idea why this
> > happens. Maybe, some sort of hardware problems?
> >
> >
> >
> >
> >  My suggestion is to back up a step and continue with HPI testing. 
You
> > should be able to do reliable "stress test" of HPI, using
random
> > combinations of read, write, different addresses, tests that run
overnight,
> > etc.
> >
> > In this way you will find the problem... maybe your Atmel code does
not
> > handle HRDY or HDS correctly, etc.  Or maybe there is still something
in the
> > errata that you have not implemented or understood completely. 
Sometimes
> > the errata can be an exercise in "reading between the lines"
to understand
> > what is really the problem -- for example something that TI does not
want to
> > admit openly.
> >
> > Then move on to bootloader.
> >
> > -Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm6467

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Thank you for reply, Michael,

By saying "DSP is in reset" I refer to the state during HPI boot,
that
is, when DSP core is held in reset while peripherals are not in reset. I
send code by means of HPI write during that state. And I get this state
by setting signal (actually, 0) on responsible DSP pin. When all code
(bootloader and appl.) is written to DSP memory I issue DSPINT.

Regards,
Taras.  
-----Original Message-----
From: Michael Dunn [mailto:m...@gmail.com] 
Sent: Friday, February 08, 2008 7:10 PM
To: Kurnytskyi Taras
Cc: Jeff Brower; c...@yahoogroups.com
Subject: Re: [c6x] HPI booting problem

Taras,

On Feb 8, 2008 10:21 AM, Kurnytskyi Taras <t...@mitaua.dk> wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet,
however
tests with
> randomly changing write/read addresses were successfully passed.
Moreover,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK - no HPI write fails. Besides, I've also noticed that
HPI
> reads fail during HPI booting.

I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.

>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP
is in
> reset and when it is running.

When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??

mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
>  Sent: Thursday, February 07, 2008 11:38 PM
>  To: Kurnytskyi Taras
>  Cc: c...@yahoogroups.com
>  Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not
ideally.
> Not ideally because I have to read only in autoincrement mode since
read in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed
mode
> is known exception to C6711 functioning. The workaround they offer is
quite
> simple, namely, they advise to use HPI read in autoincrement mode
only. This
> helped, but still I have to read the first address twice to get
correct
> values.
>
> HPI write was successful is both modes. It should be noted, however,
that
> packets exchanged between processors were rather small - not more than
40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results - DSP application starts up correctly appr. 1 time
out of
> 10 attempts. The reason of unsuccessful attempts is that some words
sent by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore
just
> a few words out of appr. 600 are invalid. And it repeats permanently.
But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe
I
> would be more optimistic if HPI write did not work at all - in that
case I
> would be sure that I missed something in HPI setting, etc. But this
random
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
>  My suggestion is to back up a step and continue with HPI testing.
You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run
overnight,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does
not
> handle HRDY or HDS correctly, etc.  Or maybe there is still something
in the
> errata that you have not implemented or understood completely.
Sometimes
> the errata can be an exercise in "reading between the lines" to
understand
> what is really the problem -- for example something that TI does not
want to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>    

-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi,

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.

Thank you in advance.

Taras.

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm6467

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Eliezer-

I am not the OP.  I believe that Taras is using 6711D.

-Jeff

PS. Please post to the group, not to me.

Eliezer wrote:

>  HiI am just in the phase of operating the HPI on the C6424 through an
ALTERA FPGA
> as the host, in two stages of course:- no boot mode   ( host write
successfull now
> read testing ...)- boot modeIs your discussions concerns the HPI on the
C6424 as
> wellThanks Eliezer Tofach
>
--------------------------------------------------------------------------------
----
> From: c...@yahoogroups.com [mailto:c...@yahoogroups.com] On Behalf Of Jeff
Brower
> Sent: Tuesday, February 12, 2008 9:02 PM
> To: Kurnytskyi Taras
> Cc: c...@yahoogroups.com
> Subject: [!! SPAM] 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
>

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jeff,

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.

By the way, how can I slow down the rate of access?  

-----Original Message-----
From: Jeff Brower [mailto:j...@signalogic.com] 
Sent: Tuesday, February 12, 2008 9:02 PM
To: Kurnytskyi Taras
Cc: c...@yahoogroups.com
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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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...@yahoogroups.com
> 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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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...@yahoogroups.com
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...@yahoogroups.com 
	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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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, 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.
>
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...@yahoogroups.com
> 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...@yahoogroups.com
>> 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
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

kurrinchi,

On Fri, Feb 22, 2008 at 12:45 PM, kurrinchi kumar balakrishnan
<k...@signalogic.com> 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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )