DSPRelated.com
Forums

Re: [Fwd: SBSRAM troubles]

Started by Tim Jones January 7, 2000
Brian,

Im slowly getting to the bottom of this, but wanted to bounce this off you
to make sure I am on the right track. The crucial issue appears to be WHEN
and WHERE to initialize the EMIF registers.

First the SBSRAM issue.

I think I found a workaround solution for the SBSRAM issue. Is this
correct? Currently, I am using MAP 1, and mapping the reset vector to
Internal Program Memory (IPRAM). The reset vector jumps to _c_int00, which
boot starts C. Then in main, I initialize the board (timers, interrupts,
etc.), and initialize the EMIF registers using my own subroutines instead
of using emif_init(). Both main and the subroutines are mapped to the
.text section, and linked into SBSRAM. The problem here is that I am
trying to re-configure the EMIF registers while operating in SBSRAM, which
of course doesnt work. (Is there a trick that I can use to do this?)
When I use the #pragma CODE_SECTION on the EMIF initialization routine
call, and map it into IPRAM, it appears I am able to effectively use the
SBSRAM.

Second: Initializing external memory in C.

This all lead me to a broader question about how to initialize external
memory and the C environment. If I attempt to initialize the external
memory in main, it assumes the C environment has been initialized. Does
that means that the bootstrap for C and the initialization routines must
operate in an area of memory that does not require hardware initialization?
Or would it be better to initialize external memory BEFORE the entering
the C environment? That would give the programmer the flexibility to map
the .text section anywhere. But does it also mean the initialization
routine must be written in assembly and called before jumping to _c_int00?

Currently, I am doing the following:

Reset jumps to _c_int00 (assembly language mapped into IPRAM)
_c_int00 initializes C environment and calls main. (mapped into IPRAM)
Main initializes the external memory (C language EMIF routine mapped into
IPRAM)

I am proposing to do the following:

Reset jumps to function that configures external memory (assembly language
mapped into IPRAM)
Configure external memory routine branches to _c_int00 (assembly language
mapped into IPRAM)
_c_int00 calls main (can be mapped anywhere).

Are my assumptions correct here or am I missing something? Another way to
ask this question is, how can I initialize my external memory in C without
falling into the Catch-22 of running in memory that I am trying to initialize.

Regards Tim

PS I discovered that I am able to initialize the SBSRAM to run at half
speed when running the initialization routine in SBSRAM. Im guessing that
this means the evm6xldr initializes the SBSRAM at half speed, and when my
code re-initializes the SBSRAM at half speed, it has no effect. However,
when I try to initialize the SBSRAM at full speed when operating out of
SBSRAM, it hangs. Have you ever experienced this?

At 11:24 PM 1/6/00 -0600, you wrote:
>Tim,
>
>Nothing else comes to mind. Could you send me
>the linker map output to see if anything else
>looks suspicious?
>
>The map mode shouldn't make a difference. I thought
>maybe it had something to do with MAP0 which maps
>the SBSRAM at address 0.
>
>I was talking about evm_init() being explicitly
>called in your main() routine.
>
>Without more information, I am not sure what else
>could be going on. As I mentioned, the only time
>I have heard of something similar is when the reset
>vectors (.vec) section was not linked in.
>
>Regards,
>Brain
>
>-------- Original Message --------
>Subject: [c6x] Re: SBSRAM troubles
>Date: Wed, 05 Jan 2000 14:49:48 -0500
>From: Tim Jones <>
>Reply-To:
>To:
>References: <>
><>
>
>Thanks for the response Brian,
>
>My reset vector does point to c_int00, and the first thing I do in main is to
>reset the evm and set the emif registers. I verified (using Code Composer)
>that the registers are being set. Is this what you mean by doing an
evm_init()
>call in my code to link in the reset vectors?
>
>I am using Map 1 instead of Map 0. How will that make a difference? My reset
>vector is placed at the beginning of internal program memory, so when
using the
>evm6xldr it is executed first which then jumps to c_int00. By the way, when I
>link to SDRAM, it seems to work fine, it's just the SBSRAM that gives me the
>trouble.
>
>Tim
>
>At 09:11 PM 1/4/00 -0600, you wrote:
>>
>> Hello,
>>
>> You may be seeing something else. Are you sure you are doing
>> an evm_init() call in your code to link in the reset vectors? This
>> is a classic symptom of this not being done (where it works in
>> CCS but not from the command loader). In CCS, the PC is set
>> to the entry point (c_int00), but when you run from the command
>> loader HPI boot is done and execution begins at address 0.
>> I assume you are using MAP0 with SBSRAM. If you don't have
>> a reset vector to c_int00, then your application won't work.
>>
>> There is no difference between the C62x and C67x in this
>> area.
>>
>> Brian
>>
>> Tim Jones wrote:
>>>
>>> Yup,
>>>
>>> I run evm6xrst first. One of the first things I do in my C67x code is to
>>> reset the EMIF registers. I'm wondering if the evm6xldr works correctly
>>> for the C67x since the EMIF registers are set differently from the C62x.
>>>
>>> Tim
>>>
>>> At 03:48 PM 1/4/00 -0600, you wrote:
>>> >
>>> >Did you reset the evm by running evm6xrst. In addition reset the EMIF
>>> >registers. In the worst case try printing out stuff to see where the code
>>> >is???
>>> >
>>> >Regards
>>> >
>>> >Jgadeesh
>>> >
>>> >
>>> >P.S:
>>> >
>>> >Disclaimer:
>>> >
>>> >TI does not in any way endorse or approve of any of the statements
>>> >above. I am merely contributing my views. TI is in no way responsible for
>>> >the result or outcome of any of my suggestions.
>>> >
>>> >On Tue, 4 Jan 2000 wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I'm trying to use SBSRAM on an EVM6701 board. When I run a COFF file,
>>> >> linked into SBSRAM, it runs OK under Code Composer, but hangs when I
>>> >> run using the evm6xldr.exe utility. I believe I am initializing my
>>> >> EMIF correctly. Any ideas as to what might be wrong?
>>> >>
>>> >> Tim
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >Want to send money instantly to anyone, anywhere, anytime?
>>> >You can today at X.com - and we'll give you $20 to try it! Sign
>>> >up today at X.com. It's quick, free, & there's no obligation!
>>>
>>> ><http://click.egrou" target="_blank" rel="nofollow">http://click.egroups.com/1/332/3/_/14737/_/947022665>http://click.egrou
>>> ps.com/1/332/3/_/14737/_/947022665
>>> >
>>> >-- Check out your group's private Chat room
>>> >--
>>> <http://www.egroups.com/" target="_blank" rel="nofollow">http://www.egroups.com/ChatPage?listName&m=1>http://www.egroups.com/
>>> ChatPage?listName&m=1
>>> >
>>>
>>>
>>> Want to send money instantly to anyone, anywhere, anytime?
>>> You can today at X.com - and we'll give you $20 to try it! Sign
>>> up today at X.com. It's quick, free, & there's no obligation!
>>>
>>> <http://click.egroup" target="_blank" rel="nofollow">http://click.egroups.com/1/332/3/_/14737/_/947023241>http://click.egroup
>>> s.com/1/332/3/_/14737/_/947023241
>>>
>>> -- Easily schedule meetings and events using the group calendar!
>>> --
>>> <http://www.egroups.com/cal?l" target="_blank" rel="nofollow">http://www.egroups.com/cal?listname&m=1>http://www.egroups.com/cal?l
>>> istname&m=1
>>
>>
>> ----------
>> eGroups.com Home:
>> <http://www.egroups.com/group/c6x" target="_blank" rel="nofollow">http://www.egroups.com/group/c6x>http://www.egroups.com/group/c6x
>> www.egroups.com - Simplifying group communications >Looking for educational tools for you kids?
>Find everything you need at SmarterKids.com
>http://click.egroups.com/1/645/3/_/14737/_/947101809
>
>-- Talk to your group with your own voice!
>-- http://www.egroups.com/VoiceChatPage?listName&m=1





Tom,

Yes, you hit upon something that we have seen before.  In fact,
the evm_init() library function used to call the emif_init()
function in earlier versions, but it was found to cause a problem
if it was being run in external memory.  This is exactly what
you have run into.

I agree with all of your assessments.

You can run evm6xrst to set the DSP speed.  The SBSRAM will
be set to the proper setting depending on the CPU clock rate.
This is something that you must be aware.  You can't run the
133 MHz SBSRAM at 1x rate when the DSP is running at 160 MHz.
The SBSRAM should be 1x rate for 133 and 1/2 rate for 160 MHz.
If you run evm6xrst with the -s option, it will initialize the EMIF
accordingly.

When you are setting the SBSRAM at 1x, are you sure the DSP
isn't set for 160 MHz.  This could be the cause of your hanging
also.

If you are running from a host application, then you initialize
it with the API call.  In the debugger (CCS), the GEL initialization
file initializes the EMIF.

If you must initialized the EMIF in your DSP application for some
reason, then yes, you must do it from IPM before you jump out
to external memory.  Your idea about doing an interim jump
to assembly code before jumping to c_int00() should work fine.

Brian

Tim Jones wrote:

Brian,

Im slowly getting to the bottom of this, but wanted to bounce this off you
to make sure I am on the right track.  The crucial issue appears to be WHEN
and WHERE to initialize the EMIF registers.

First the SBSRAM issue.

I think I found a workaround solution for the SBSRAM issue.  Is this
correct?  Currently, I am using MAP 1, and mapping the reset vector to
Internal Program Memory (IPRAM).  The reset vector jumps to _c_int00, which
boot starts C.  Then in main, I initialize the board (timers, interrupts,
etc.), and initialize the EMIF registers using my own subroutines instead
of using emif_init().  Both main and the subroutines are mapped to the
.text section, and linked into SBSRAM.  The problem here is that I am
trying to re-configure the EMIF registers while operating in SBSRAM, which
of course doesnt work.  (Is there a trick that I can use to do this?)
When I use the #pragma CODE_SECTION on the EMIF initialization routine
call, and map it into IPRAM, it appears I am able to effectively use the
SBSRAM.

Second:  Initializing external memory in C.

This all lead me to a broader question about how to initialize external
memory and the C environment.  If I attempt to initialize the external
memory in main, it assumes the C environment has been initialized.  Does
that means that the bootstrap for C and the initialization routines must
operate in an area of memory that does not require hardware initialization?
 Or would it be better to initialize external memory BEFORE the entering
the C environment?  That would give the programmer the flexibility to map
the .text section anywhere. But does it also mean the initialization
routine must be written in assembly and called before jumping to _c_int00?

Currently, I am doing the following:

Reset jumps to _c_int00 (assembly language mapped into IPRAM)
_c_int00 initializes C environment and calls main. (mapped into IPRAM)
Main initializes the external memory (C language EMIF routine mapped into
IPRAM)

I am proposing to do the following:

Reset jumps to function that configures external memory (assembly language
mapped into IPRAM)
Configure external memory routine branches to _c_int00 (assembly language
mapped into IPRAM)
_c_int00 calls main (can be mapped anywhere).

Are my assumptions correct here or am I missing something?  Another way to
ask this question is, how can I initialize my external memory in C without
falling into the Catch-22 of running in memory that I am trying to initialize.

Regards  Tim

PS  I discovered that I am able to initialize the SBSRAM to run at half
speed when running the initialization routine in SBSRAM.  Im guessing that
this means the evm6xldr initializes the SBSRAM at half speed, and when my
code re-initializes the SBSRAM at half speed, it has no effect.  However,
when I try to initialize the SBSRAM at full speed when operating out of
SBSRAM, it hangs.  Have you ever experienced this?

At 11:24 PM 1/6/00 -0600, you wrote:
>Tim,
>
>Nothing else comes to mind.  Could you send me
>the linker map output to see if anything else
>looks suspicious?
>
>The map mode shouldn't make a difference.  I thought
>maybe it had something to do with MAP0 which maps
>the SBSRAM at address 0.
>
>I was talking about evm_init() being explicitly
>called in your main() routine.
>
>Without more information, I am not sure what else
>could be going on.  As I mentioned, the only time
>I have heard of something similar is when the reset
>vectors (.vec) section was not linked in.
>
>Regards,
>Brain
>
>-------- Original Message --------
>Subject: [c6x] Re: SBSRAM troubles
>Date: Wed, 05 Jan 2000 14:49:48 -0500
>From: Tim Jones <t...@mathworks.com>
>Reply-To: c...@eGroups.com
>To: c...@eGroups.com
>References: <84tp8h$7...@eGroups.com>
><4...@pop.mathworks.com>
>
>Thanks for the response Brian,
>
>My reset vector does point to c_int00, and the first thing I do in main is to
>reset the evm and set the emif registers.  I verified (using Code Composer)
>that the registers are being set.  Is this what you mean by doing an
evm_init()
>call in my code to link in the reset vectors?
>
>I am using Map 1 instead of Map 0.  How will that make a difference?  My reset
>vector is placed at the beginning of internal program memory, so when
using the
>evm6xldr it is executed first which then jumps to c_int00.  By the way, when I
>link to SDRAM, it seems to work fine, it's just the SBSRAM that gives me the
>trouble.
>
>Tim
>
>At 09:11 PM 1/4/00 -0600, you wrote:
>>
>> Hello,
>>
>> You may be seeing something else.  Are you sure you are doing
>> an evm_init() call in your code to link in the reset vectors?   This
>> is a classic symptom of  this not being done (where it works in
>> CCS but not from the command loader).  In CCS, the PC is set
>> to the entry point (c_int00), but when you run from the command
>> loader HPI boot is done and execution begins at address 0.
>> I assume you are using MAP0 with SBSRAM.  If you don't have
>> a reset vector to c_int00, then your application won't work.
>>
>> There is no difference between the C62x and C67x in this
>> area.
>>
>> Brian
>>
>> Tim Jones wrote:
>>>
>>> Yup,
>>>
>>> I run evm6xrst first.  One of the first things I do in my C67x code is to
>>> reset the EMIF registers.  I'm wondering if the evm6xldr works correctly
>>> for the C67x since the EMIF registers are set differently from the C62x.
>>>
>>> Tim
>>>
>>> At 03:48 PM 1/4/00 -0600, you wrote:
>>> >
>>> >Did you reset the evm by running evm6xrst. In addition reset the EMIF
>>> >registers. In the worst case try printing out stuff to see where the code
>>> >is???
>>> >
>>> >Regards
>>> >
>>> >Jgadeesh
>>> >s...@ti.com
>>> >
>>> >P.S:
>>> >
>>> >Disclaimer:
>>> >
>>> >TI does not in any way endorse or approve of any of the statements
>>> >above. I am merely contributing my views. TI is in no way responsible for
>>> >the result or outcome of any of my suggestions.
>>> >
>>> >On Tue, 4 Jan 2000 t...@mathworks.com wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I'm trying to use SBSRAM on an EVM6701 board.  When I run a COFF file,
>>> >> linked into SBSRAM, it runs OK under Code Composer, but hangs when I
>>> >> run using the evm6xldr.exe utility.  I believe I am initializing my
>>> >> EMIF correctly.  Any ideas as to what might be wrong?
>>> >>
>>> >> Tim
>>> >>
>>> >>
>>> >>
>>> >>

>>> >> Want to send money instantly to anyone, anywhere, anytime?
>>> >> You can today at X.com - and we'll give you $20 to try it!  Sign
>>> >> up today at X.com.  It's quick, free, & there's no obligation!
>>> >>
>>> <http://click.egroup" target="_blank" rel="nofollow">http://click.egroups.com/1/332/3/_/14737/_/947021910>http://click.egroup
>>> s.com/1/332/3/_/14737/_/947021910
>>> >>
>>> >> eGroups.com Home:
>>> <http://www.egroups.com/group/c6x/" target="_blank" rel="nofollow">http://www.egroups.com/group/c6x/>http://www.egroups.com/group/c6x/
>>> >> http://www.egroups.com - Simplifying group communications
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >Want to send money instantly to anyone, anywhere, anytime?
>>> >You can today at X.com - and we'll give you $20 to try it!  Sign
>>> >up today at X.com.  It's quick, free, & there's no obligation!
>>>
>>> ><http://click.egrou" target="_blank" rel="nofollow">http://click.egroups.com/1/332/3/_/14737/_/947022665>http://click.egrou
>>> ps.com/1/332/3/_/14737/_/947022665
>>> >
>>> >-- Check out your group's private Chat room
>>> >--
>>> <http://www.egroups.com/" target="_blank" rel="nofollow">http://www.egroups.com/ChatPage?listName&m=1>http://www.egroups.com/
>>> ChatPage?listName&m=1
>>> >
>>>
>>>
>>> Want to send money instantly to anyone, anywhere, anytime?
>>> You can today at X.com - and we'll give you $20 to try it!  Sign
>>> up today at X.com.  It's quick, free, & there's no obligation!
>>>
>>> <http://click.egroup" target="_blank" rel="nofollow">http://click.egroups.com/1/332/3/_/14737/_/947023241>http://click.egroup
>>> s.com/1/332/3/_/14737/_/947023241
>>>
>>> -- Easily schedule meetings and events using the group calendar!
>>> --
>>> <http://www.egroups.com/cal?l" target="_blank" rel="nofollow">http://www.egroups.com/cal?listname&m=1>http://www.egroups.com/cal?l
>>> istname&m=1
>>
>>
>> ----------
>> eGroups.com Home:
>> <http://www.egroups.com/group/c6x" target="_blank" rel="nofollow">http://www.egroups.com/group/c6x>http://www.egroups.com/group/c6x
>> www.egroups.com - Simplifying group communications
>
>
>
>
>
>Looking for educational tools for you kids?
>Find everything you need at SmarterKids.com
>http://click.egroups.com/1/645/3/_/14737/_/947101809
>
>-- Talk to your group with your own voice!
>-- http://www.egroups.com/VoiceChatPage?listName&m=1


Want to send money instantly to anyone, anywhere, anytime?
You can today at X.com - and we'll give you $20 to try it!  Sign
up today at X.com.  It's quick, free, & there's no obligation!
http://click.egroups.com/1/332/3/_/14737/_/947268170/

-- Create a poll/survey for your group!
-- http://www.egroups.com/vote?listname&m=1