All,
I am using the eInfochips EVM6205 board to prototype a C6205 embedded
system.
My system must use the MAP 0 memory map which requires booting from SDRAM
located on CE0 at 0 x 0000_0000 h.
I have been unable to get the EVM6205 to boot successfully into MAP 0
using the boot mode switches from power up and hard reset. The contents of
the SDRAM are corrupted as they are loaded from the ROM by the hardware
boot loader. I can use the JTAG emulator to reset the DSP core and rerun
the hardware boot loader. This corrects the corrupted SDRAM locations and
allows the DSP to run.
When I connected a logic analyzer to capture both SDRAM accesses and ROM
accesses. I saw some very puzzling things...
The some type of SDRAM initialization is occurring sometime after RESET is
asserted (goes low), and before it is released (goes high). The DSP then
reads the ROM starting from address 0 x 0100_0000 h. It looks like the
correct byte values are read. Next, the DSP writes what looks like the
correct values into the SDRAM. The RESET signal is still asserted during
this entire time !
TI DSP help stated that this is not possible. Hardware boot loading does
not occur until after RESET is released per SPRS106 and SPRU642.
I am beginning to question the accuracy of the TI documentation.
To better understand the boot process, I loaded a version of test code
that is compiled for MAP 1 and internal RAM.
The analyzer shows the processor reading from ROM and loading internal RAM
(MAP 1) while the RESET pin is asserted (low). The correct boot mode
information of 0 x 0880_016D h is placed on the bus after RESET is
asserted. The ROM chip enable falls, and the address begins to increment
as the bytes used to build the first instruction are read from the ROM
while RESET is still asserted.
For the DSP to 'know' that the boot mode is MAP 1 using an 8 bit ROM,
it
must have read the boot mode pins some time after the reset line was
asserted but before the ROM was chip enabled.
I have also captured a sequence showing PCI BOOT. In this case the chip
enable for the ROM does NOT become active. This is to be expected for PCI
boot because the load will be coming through the PCI resource. However, it
indicates again that the DSP has read the value of 0 x 0880 0167 h from
the data bus almost immediately after the RESET line is asserted.
This is not the sequence described by the TI doc's. SPRU642 describes the
ROM boot process as: " The program located in external ROM is copied to
address 0 by the DMA controller. Although the boot process begins when the
device is released from external reset, this transfer occurs while the CPU
is internally stalled." The RESET signal timing shown in SPRS106E further
indicates that there should be no external bus activity until after RESET
is released and the boot configuration is detected by the rising edge of
reset.
Has anyone ever successfully booted a C6205 into MAP 0 from an 8 bit ROM
to SDRAM located on CE0 at 0 x 0000_0000 h?
Has anyone else seen hardware boot loader activity on the C6205 EMIF while
RESET is still asserted?
Thank you,
Regards,
Joe Futey
Senior Design Engineer
LDS Test and Measurement
C6205 hardware boot loader / SDRAM problem
Started by ●October 12, 2005
Reply by ●October 12, 20052005-10-12
Hello Joe,
Please see comments below.
--- joe.futey@joe.... wrote:
> All,
>
> I am using the eInfochips EVM6205 board to prototype
> a C6205 embedded
> system.
>
> My system must use the MAP 0 memory map which
> requires booting from SDRAM
> located on CE0 at 0 x 0000_0000 h.
>
> I have been unable to get the EVM6205 to boot
> successfully into MAP 0
> using the boot mode switches from power up and hard
> reset. The contents of
> the SDRAM are corrupted as they are loaded from the
> ROM by the hardware
> boot loader. I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run.
>
> When I connected a logic analyzer to capture both
> SDRAM accesses and ROM
> accesses. I saw some very puzzling things...
>
> The some type of SDRAM initialization is occurring
> sometime after RESET is
> asserted (goes low), and before it is released (goes
> high). The DSP then
> reads the ROM starting from address 0 x 0100_0000 h.
> It looks like the
> correct byte values are read. Next, the DSP writes
> what looks like the
> correct values into the SDRAM. The RESET signal is
> still asserted during
> this entire time !
>
> TI DSP help stated that this is not possible.
> Hardware boot loading does
> not occur until after RESET is released per SPRS106
> and SPRU642.
>
> I am beginning to question the accuracy of the TI
> documentation.
>
> To better understand the boot process, I loaded a
> version of test code
> that is compiled for MAP 1 and internal RAM.
>
> The analyzer shows the processor reading from ROM
> and loading internal RAM
> (MAP 1) while the RESET pin is asserted (low). The
> correct boot mode
> information of 0 x 0880_016D h is placed on the bus
> after RESET is
> asserted. The ROM chip enable falls, and the
> address begins to increment
> as the bytes used to build the first instruction are
> read from the ROM
> while RESET is still asserted.
>
> For the DSP to 'know' that the boot mode is MAP 1
> using an 8 bit ROM, it
> must have read the boot mode pins some time after
> the reset line was
> asserted but before the ROM was chip enabled.
>
> I have also captured a sequence showing PCI BOOT. In
> this case the chip
> enable for the ROM does NOT become active. This is
> to be expected for PCI
> boot because the load will be coming through the PCI
> resource. However, it
> indicates again that the DSP has read the value of 0
> x 0880 0167 h from
> the data bus almost immediately after the RESET line
> is asserted.
>
> This is not the sequence described by the TI doc's.
> SPRU642 describes the
> ROM boot process as: " The program located in
> external ROM is copied to
> address 0 by the DMA controller. Although the boot
> process begins when the
> device is released from external reset, this
> transfer occurs while the CPU
> is internally stalled." The RESET signal timing
> shown in SPRS106E further
> indicates that there should be no external bus
> activity until after RESET
> is released and the boot configuration is detected
> by the rising edge of
> reset.
>
> Has anyone ever successfully booted a C6205 into MAP
> 0 from an 8 bit ROM
> to SDRAM located on CE0 at 0 x 0000_0000 h?
>
> Has anyone else seen hardware boot loader activity
> on the C6205 EMIF while
> RESET is still asserted?
It has been some time since I worked with boot issues
on a 620x/6701 device. Two things that I can say for
certain - [1] the 621x/671x/641x devices behave very
differently than 620x/6701 device WRT booting and [2]
the documents to which you refer accurately describe
the 621x/671x/641x device boot behavior.
I have seen systems that operated in various boot
modes, but the only ones that I have seen that begin
execution from SDRAM are those that operate in host
boot mode. If I was in your situation, I would go to
plan B and use a two level boot process. Go ahead and
boot to internal RAM and then intialize the EMIF and
copy the ROM to SDRAM. Although the process is a bit
slower, the actual time from the rising edge of Reset
should be close to the "advertised boot time" from the
rising edge of Reset.
News flash -
I just refered to spru190a [1997 hard copy] and found
the following -
"Although the boot process begins when the device is
released from external reset, this transfer occurs
while the CPU is internally held in reset."
One possibility is that the 'default SDRAM timing'
that is hardwired into the device may not be
compatible with contemporary SDRAM devices.
Another thought is that the reset pulse is too long
[that's a switch] and causing some undersirable side
effect [killing refresh??]
RE:
"I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run."
How did you do this?? Did you configure the EMIF
first??
mikedunn >
> Thank you,
>
> Regards,
>
> Joe Futey
> Senior Design Engineer
>
> LDS Test and Measurement > c6x-unsubscribe@c6x-... >
>
Please see comments below.
--- joe.futey@joe.... wrote:
> All,
>
> I am using the eInfochips EVM6205 board to prototype
> a C6205 embedded
> system.
>
> My system must use the MAP 0 memory map which
> requires booting from SDRAM
> located on CE0 at 0 x 0000_0000 h.
>
> I have been unable to get the EVM6205 to boot
> successfully into MAP 0
> using the boot mode switches from power up and hard
> reset. The contents of
> the SDRAM are corrupted as they are loaded from the
> ROM by the hardware
> boot loader. I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run.
>
> When I connected a logic analyzer to capture both
> SDRAM accesses and ROM
> accesses. I saw some very puzzling things...
>
> The some type of SDRAM initialization is occurring
> sometime after RESET is
> asserted (goes low), and before it is released (goes
> high). The DSP then
> reads the ROM starting from address 0 x 0100_0000 h.
> It looks like the
> correct byte values are read. Next, the DSP writes
> what looks like the
> correct values into the SDRAM. The RESET signal is
> still asserted during
> this entire time !
>
> TI DSP help stated that this is not possible.
> Hardware boot loading does
> not occur until after RESET is released per SPRS106
> and SPRU642.
>
> I am beginning to question the accuracy of the TI
> documentation.
>
> To better understand the boot process, I loaded a
> version of test code
> that is compiled for MAP 1 and internal RAM.
>
> The analyzer shows the processor reading from ROM
> and loading internal RAM
> (MAP 1) while the RESET pin is asserted (low). The
> correct boot mode
> information of 0 x 0880_016D h is placed on the bus
> after RESET is
> asserted. The ROM chip enable falls, and the
> address begins to increment
> as the bytes used to build the first instruction are
> read from the ROM
> while RESET is still asserted.
>
> For the DSP to 'know' that the boot mode is MAP 1
> using an 8 bit ROM, it
> must have read the boot mode pins some time after
> the reset line was
> asserted but before the ROM was chip enabled.
>
> I have also captured a sequence showing PCI BOOT. In
> this case the chip
> enable for the ROM does NOT become active. This is
> to be expected for PCI
> boot because the load will be coming through the PCI
> resource. However, it
> indicates again that the DSP has read the value of 0
> x 0880 0167 h from
> the data bus almost immediately after the RESET line
> is asserted.
>
> This is not the sequence described by the TI doc's.
> SPRU642 describes the
> ROM boot process as: " The program located in
> external ROM is copied to
> address 0 by the DMA controller. Although the boot
> process begins when the
> device is released from external reset, this
> transfer occurs while the CPU
> is internally stalled." The RESET signal timing
> shown in SPRS106E further
> indicates that there should be no external bus
> activity until after RESET
> is released and the boot configuration is detected
> by the rising edge of
> reset.
>
> Has anyone ever successfully booted a C6205 into MAP
> 0 from an 8 bit ROM
> to SDRAM located on CE0 at 0 x 0000_0000 h?
>
> Has anyone else seen hardware boot loader activity
> on the C6205 EMIF while
> RESET is still asserted?
It has been some time since I worked with boot issues
on a 620x/6701 device. Two things that I can say for
certain - [1] the 621x/671x/641x devices behave very
differently than 620x/6701 device WRT booting and [2]
the documents to which you refer accurately describe
the 621x/671x/641x device boot behavior.
I have seen systems that operated in various boot
modes, but the only ones that I have seen that begin
execution from SDRAM are those that operate in host
boot mode. If I was in your situation, I would go to
plan B and use a two level boot process. Go ahead and
boot to internal RAM and then intialize the EMIF and
copy the ROM to SDRAM. Although the process is a bit
slower, the actual time from the rising edge of Reset
should be close to the "advertised boot time" from the
rising edge of Reset.
News flash -
I just refered to spru190a [1997 hard copy] and found
the following -
"Although the boot process begins when the device is
released from external reset, this transfer occurs
while the CPU is internally held in reset."
One possibility is that the 'default SDRAM timing'
that is hardwired into the device may not be
compatible with contemporary SDRAM devices.
Another thought is that the reset pulse is too long
[that's a switch] and causing some undersirable side
effect [killing refresh??]
RE:
"I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run."
How did you do this?? Did you configure the EMIF
first??
mikedunn >
> Thank you,
>
> Regards,
>
> Joe Futey
> Senior Design Engineer
>
> LDS Test and Measurement > c6x-unsubscribe@c6x-... >
>
Reply by ●October 12, 20052005-10-12
Mike,
We are using the 'C6205 in an embedded system that is not part of a PC.
The 'C6205 is on an internal PCI bus used to communicate to other PCI
peripherals. Consequently it takes too long to load the boot code into the
DSP in host boot mode. The DSP application is larger than 64K and requires
that the internal RAM be used as cache to support the required execution
speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as the
best possible option for us. After all, it is an advertised option...
I performed the following experiments in an attempt to debug the SDRAM
problem.
1.) Disable the FLASH ram so there is not code to fetch.
2.) Let the DSP come out of reset so the BOOTMODE is read and the EMIF
defaults are set.
3.) Using the EJTAG XDS510 USB emulator connected without a GEL file and
read the EMIF configuration:
GBCTL 0x 0000 3778 h
0000 3 = reserved
7 = ardy, hold, holda are logic high, should be ok
7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN is 1 (SSCLK enabled),
CLK1EN is 1 (CLKOUT1 enabled)
8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM at address 0x0000
0000h)
SDCTL 0x 0788 F000 h
0000 = reserved
7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh enabled), INIT is 1,
(undefined for reads)
8 = TRCD is 1000 = 90 ns (part requires 20 ns or greater).
8 = TRP is 1000 = 90 ns (part requires 20 ns or greater).
F= TRC is 1111 = 160 ns (part requires 70 ns or greater).
000 = reserved
SDTIM 0x 0003 B040 h
00 = reserved
03B = counter value (always changing)
040 = refresh period = 640 ns (part requires 15.625 u sec or less)
CECTL0 0x FFFF 3F33 h
xxxx xx3x = M-Type is 32 bit SDRAM. Everything else is "don't care"
O.K., everything looks fine to me at this point.
4.) Using the XDS510 and CCS (with no GEL file) we can 'peek and poke'
into SDRAM. The memory seems fully functional and stable.
5.) Disconnect the emulator via CCS, power down the system and enable the
flash ram.
6.) Power up the system, reset the DSP using the push button, connect with
CCS via the XDS510.
7.) Verify that the EMIF configuration is correct. It is the same as
above.
8.) Inspecting the contents of the SDRAM, we can see an immediate problem. The secondary bootloader code has not been correctly copied into the
SDRAM. Many instructions are just fine, but some instructions appear to
have gotten a few bits flipped. This, of course, is a very bad thing that
has lead the secondary boot loader to crash.
9.) Using CCS and the XDS510, issue an EJTAG reset.
10.) We can see the instructions in SDRAM change to the correct values.
They are nicely highlighted in red by CCS. The code boots and runs
normally.
The problem persists at 20 MHz as well as 200 MHz. I have changed the boot
mode switches to bypass the PLL and run at 20 MHz. I have re-verified the
SDRAM timing using 20 MHz defaults and it is O.K.
There is no operating system present. The board is being used stand alone,
not in any PC.
TI - DSP help says that SPRU190A has been superseded by the combination of
SPRS106E and SPRU642.
My logic analyzer trace dumps show SDRAM initialization, fetches from the
ROM and instruction writes to SDRAM occurring while DSP RESET is asserted.
The EMIF SDRAM clock during the initialization is not stable at all and I
think that is part of the problem. This seems like a pretty egregious
error both in documentation and implementation. I wouldn't expect to see
something like this from TI. I keep hoping that I'm doing something wrong.
I've scanned in the trace dumps and have them as PDF's if you would like
to see them.
Thanks for the prompt response.
Joe
Mike Dunn <mike-dunn@mike...>
Sent by: c6x@c6x@...
10/12/2005 03:45 PM
To
joe.futey@joe...., c6x@c6x@...
cc
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Hello Joe,
Please see comments below.
--- joe.futey@joe.... wrote:
> All,
>
> I am using the eInfochips EVM6205 board to prototype
> a C6205 embedded
> system.
>
> My system must use the MAP 0 memory map which
> requires booting from SDRAM
> located on CE0 at 0 x 0000_0000 h.
>
> I have been unable to get the EVM6205 to boot
> successfully into MAP 0
> using the boot mode switches from power up and hard
> reset. The contents of
> the SDRAM are corrupted as they are loaded from the
> ROM by the hardware
> boot loader. I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run.
>
> When I connected a logic analyzer to capture both
> SDRAM accesses and ROM
> accesses. I saw some very puzzling things...
>
> The some type of SDRAM initialization is occurring
> sometime after RESET is
> asserted (goes low), and before it is released (goes
> high). The DSP then
> reads the ROM starting from address 0 x 0100_0000 h.
> It looks like the
> correct byte values are read. Next, the DSP writes
> what looks like the
> correct values into the SDRAM. The RESET signal is
> still asserted during
> this entire time !
>
> TI DSP help stated that this is not possible.
> Hardware boot loading does
> not occur until after RESET is released per SPRS106
> and SPRU642.
>
> I am beginning to question the accuracy of the TI
> documentation.
>
> To better understand the boot process, I loaded a
> version of test code
> that is compiled for MAP 1 and internal RAM.
>
> The analyzer shows the processor reading from ROM
> and loading internal RAM
> (MAP 1) while the RESET pin is asserted (low). The
> correct boot mode
> information of 0 x 0880_016D h is placed on the bus
> after RESET is
> asserted. The ROM chip enable falls, and the
> address begins to increment
> as the bytes used to build the first instruction are
> read from the ROM
> while RESET is still asserted.
>
> For the DSP to 'know' that the boot mode is MAP 1
> using an 8 bit ROM, it
> must have read the boot mode pins some time after
> the reset line was
> asserted but before the ROM was chip enabled.
>
> I have also captured a sequence showing PCI BOOT. In
> this case the chip
> enable for the ROM does NOT become active. This is
> to be expected for PCI
> boot because the load will be coming through the PCI
> resource. However, it
> indicates again that the DSP has read the value of 0
> x 0880 0167 h from
> the data bus almost immediately after the RESET line
> is asserted.
>
> This is not the sequence described by the TI doc's.
> SPRU642 describes the
> ROM boot process as: " The program located in
> external ROM is copied to
> address 0 by the DMA controller. Although the boot
> process begins when the
> device is released from external reset, this
> transfer occurs while the CPU
> is internally stalled." The RESET signal timing
> shown in SPRS106E further
> indicates that there should be no external bus
> activity until after RESET
> is released and the boot configuration is detected
> by the rising edge of
> reset.
>
> Has anyone ever successfully booted a C6205 into MAP
> 0 from an 8 bit ROM
> to SDRAM located on CE0 at 0 x 0000_0000 h?
>
> Has anyone else seen hardware boot loader activity
> on the C6205 EMIF while
> RESET is still asserted?
It has been some time since I worked with boot issues
on a 620x/6701 device. Two things that I can say for
certain - [1] the 621x/671x/641x devices behave very
differently than 620x/6701 device WRT booting and [2]
the documents to which you refer accurately describe
the 621x/671x/641x device boot behavior.
I have seen systems that operated in various boot
modes, but the only ones that I have seen that begin
execution from SDRAM are those that operate in host
boot mode. If I was in your situation, I would go to
plan B and use a two level boot process. Go ahead and
boot to internal RAM and then intialize the EMIF and
copy the ROM to SDRAM. Although the process is a bit
slower, the actual time from the rising edge of Reset
should be close to the "advertised boot time" from the
rising edge of Reset.
News flash -
I just refered to spru190a [1997 hard copy] and found
the following -
"Although the boot process begins when the device is
released from external reset, this transfer occurs
while the CPU is internally held in reset."
One possibility is that the 'default SDRAM timing'
that is hardwired into the device may not be
compatible with contemporary SDRAM devices.
Another thought is that the reset pulse is too long
[that's a switch] and causing some undersirable side
effect [killing refresh??]
RE:
"I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run."
How did you do this?? Did you configure the EMIF
first??
mikedunn
We are using the 'C6205 in an embedded system that is not part of a PC.
The 'C6205 is on an internal PCI bus used to communicate to other PCI
peripherals. Consequently it takes too long to load the boot code into the
DSP in host boot mode. The DSP application is larger than 64K and requires
that the internal RAM be used as cache to support the required execution
speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as the
best possible option for us. After all, it is an advertised option...
I performed the following experiments in an attempt to debug the SDRAM
problem.
1.) Disable the FLASH ram so there is not code to fetch.
2.) Let the DSP come out of reset so the BOOTMODE is read and the EMIF
defaults are set.
3.) Using the EJTAG XDS510 USB emulator connected without a GEL file and
read the EMIF configuration:
GBCTL 0x 0000 3778 h
0000 3 = reserved
7 = ardy, hold, holda are logic high, should be ok
7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN is 1 (SSCLK enabled),
CLK1EN is 1 (CLKOUT1 enabled)
8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM at address 0x0000
0000h)
SDCTL 0x 0788 F000 h
0000 = reserved
7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh enabled), INIT is 1,
(undefined for reads)
8 = TRCD is 1000 = 90 ns (part requires 20 ns or greater).
8 = TRP is 1000 = 90 ns (part requires 20 ns or greater).
F= TRC is 1111 = 160 ns (part requires 70 ns or greater).
000 = reserved
SDTIM 0x 0003 B040 h
00 = reserved
03B = counter value (always changing)
040 = refresh period = 640 ns (part requires 15.625 u sec or less)
CECTL0 0x FFFF 3F33 h
xxxx xx3x = M-Type is 32 bit SDRAM. Everything else is "don't care"
O.K., everything looks fine to me at this point.
4.) Using the XDS510 and CCS (with no GEL file) we can 'peek and poke'
into SDRAM. The memory seems fully functional and stable.
5.) Disconnect the emulator via CCS, power down the system and enable the
flash ram.
6.) Power up the system, reset the DSP using the push button, connect with
CCS via the XDS510.
7.) Verify that the EMIF configuration is correct. It is the same as
above.
8.) Inspecting the contents of the SDRAM, we can see an immediate problem. The secondary bootloader code has not been correctly copied into the
SDRAM. Many instructions are just fine, but some instructions appear to
have gotten a few bits flipped. This, of course, is a very bad thing that
has lead the secondary boot loader to crash.
9.) Using CCS and the XDS510, issue an EJTAG reset.
10.) We can see the instructions in SDRAM change to the correct values.
They are nicely highlighted in red by CCS. The code boots and runs
normally.
The problem persists at 20 MHz as well as 200 MHz. I have changed the boot
mode switches to bypass the PLL and run at 20 MHz. I have re-verified the
SDRAM timing using 20 MHz defaults and it is O.K.
There is no operating system present. The board is being used stand alone,
not in any PC.
TI - DSP help says that SPRU190A has been superseded by the combination of
SPRS106E and SPRU642.
My logic analyzer trace dumps show SDRAM initialization, fetches from the
ROM and instruction writes to SDRAM occurring while DSP RESET is asserted.
The EMIF SDRAM clock during the initialization is not stable at all and I
think that is part of the problem. This seems like a pretty egregious
error both in documentation and implementation. I wouldn't expect to see
something like this from TI. I keep hoping that I'm doing something wrong.
I've scanned in the trace dumps and have them as PDF's if you would like
to see them.
Thanks for the prompt response.
Joe
Mike Dunn <mike-dunn@mike...>
Sent by: c6x@c6x@...
10/12/2005 03:45 PM
To
joe.futey@joe...., c6x@c6x@...
cc
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Hello Joe,
Please see comments below.
--- joe.futey@joe.... wrote:
> All,
>
> I am using the eInfochips EVM6205 board to prototype
> a C6205 embedded
> system.
>
> My system must use the MAP 0 memory map which
> requires booting from SDRAM
> located on CE0 at 0 x 0000_0000 h.
>
> I have been unable to get the EVM6205 to boot
> successfully into MAP 0
> using the boot mode switches from power up and hard
> reset. The contents of
> the SDRAM are corrupted as they are loaded from the
> ROM by the hardware
> boot loader. I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run.
>
> When I connected a logic analyzer to capture both
> SDRAM accesses and ROM
> accesses. I saw some very puzzling things...
>
> The some type of SDRAM initialization is occurring
> sometime after RESET is
> asserted (goes low), and before it is released (goes
> high). The DSP then
> reads the ROM starting from address 0 x 0100_0000 h.
> It looks like the
> correct byte values are read. Next, the DSP writes
> what looks like the
> correct values into the SDRAM. The RESET signal is
> still asserted during
> this entire time !
>
> TI DSP help stated that this is not possible.
> Hardware boot loading does
> not occur until after RESET is released per SPRS106
> and SPRU642.
>
> I am beginning to question the accuracy of the TI
> documentation.
>
> To better understand the boot process, I loaded a
> version of test code
> that is compiled for MAP 1 and internal RAM.
>
> The analyzer shows the processor reading from ROM
> and loading internal RAM
> (MAP 1) while the RESET pin is asserted (low). The
> correct boot mode
> information of 0 x 0880_016D h is placed on the bus
> after RESET is
> asserted. The ROM chip enable falls, and the
> address begins to increment
> as the bytes used to build the first instruction are
> read from the ROM
> while RESET is still asserted.
>
> For the DSP to 'know' that the boot mode is MAP 1
> using an 8 bit ROM, it
> must have read the boot mode pins some time after
> the reset line was
> asserted but before the ROM was chip enabled.
>
> I have also captured a sequence showing PCI BOOT. In
> this case the chip
> enable for the ROM does NOT become active. This is
> to be expected for PCI
> boot because the load will be coming through the PCI
> resource. However, it
> indicates again that the DSP has read the value of 0
> x 0880 0167 h from
> the data bus almost immediately after the RESET line
> is asserted.
>
> This is not the sequence described by the TI doc's.
> SPRU642 describes the
> ROM boot process as: " The program located in
> external ROM is copied to
> address 0 by the DMA controller. Although the boot
> process begins when the
> device is released from external reset, this
> transfer occurs while the CPU
> is internally stalled." The RESET signal timing
> shown in SPRS106E further
> indicates that there should be no external bus
> activity until after RESET
> is released and the boot configuration is detected
> by the rising edge of
> reset.
>
> Has anyone ever successfully booted a C6205 into MAP
> 0 from an 8 bit ROM
> to SDRAM located on CE0 at 0 x 0000_0000 h?
>
> Has anyone else seen hardware boot loader activity
> on the C6205 EMIF while
> RESET is still asserted?
It has been some time since I worked with boot issues
on a 620x/6701 device. Two things that I can say for
certain - [1] the 621x/671x/641x devices behave very
differently than 620x/6701 device WRT booting and [2]
the documents to which you refer accurately describe
the 621x/671x/641x device boot behavior.
I have seen systems that operated in various boot
modes, but the only ones that I have seen that begin
execution from SDRAM are those that operate in host
boot mode. If I was in your situation, I would go to
plan B and use a two level boot process. Go ahead and
boot to internal RAM and then intialize the EMIF and
copy the ROM to SDRAM. Although the process is a bit
slower, the actual time from the rising edge of Reset
should be close to the "advertised boot time" from the
rising edge of Reset.
News flash -
I just refered to spru190a [1997 hard copy] and found
the following -
"Although the boot process begins when the device is
released from external reset, this transfer occurs
while the CPU is internally held in reset."
One possibility is that the 'default SDRAM timing'
that is hardwired into the device may not be
compatible with contemporary SDRAM devices.
Another thought is that the reset pulse is too long
[that's a switch] and causing some undersirable side
effect [killing refresh??]
RE:
"I can use the JTAG emulator to reset
> the DSP core and rerun
> the hardware boot loader. This corrects the
> corrupted SDRAM locations and
> allows the DSP to run."
How did you do this?? Did you configure the EMIF
first??
mikedunn
Reply by ●October 12, 20052005-10-12
Joe,
I have included my comments in line below.
mikedunn
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> We are using the 'C6205 in an embedded system that
> is not part of a PC.
> The 'C6205 is on an internal PCI bus used to
> communicate to other PCI
> peripherals. Consequently it takes too long to load
> the boot code into the
> DSP in host boot mode. The DSP application is larger
> than 64K and requires
> that the internal RAM be used as cache to support
> the required execution
> speed, so MAP 1 cannot be used.
>>mike>>Why can't Map1 be used?? I think that booting
the secondary loader into internal memory,
initializing and loading SDRAM, jumping to SDRAM and
then enabling 'cache mode' is the way to go. Even if
your original plan of booting to SDRAM worked, you
would be stuck with less than optimum EMIF
initialization. > That leaves MAP 0
> boot from flash as the
> best possible option for us. After all, it is an
> advertised option...
> I performed the following experiments in an attempt
> to debug the SDRAM
> problem.
>
> 1.) Disable the FLASH ram so there is not code to
> fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is
> read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected
> without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN
> is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh
> enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or
> greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625
> u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else
> is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we
> can 'peek and poke'
> into SDRAM. The memory seems fully functional and
> stable.
>
> 5.) Disconnect the emulator via CCS, power down the
> system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the
> push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct.
> It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see
> an immediate problem. > The secondary bootloader code has not been correctly
> copied into the
> SDRAM. Many instructions are just fine, but some
> instructions appear to
> have gotten a few bits flipped. This, of course, is
> a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>>mike>>Please forgive my ignorance - What is an
"EJTAG reset"?? I am not accustomed to seeing 'EJTAG'
in relation to TI.
>
> 10.) We can see the instructions in SDRAM change to
> the correct values.
> They are nicely highlighted in red by CCS. The code
> boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I
> have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I
> have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is
> being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded
> by the combination of
> SPRS106E and SPRU642.
>>mike>>I know. My comment was in relation to the
possibility that some of the info got "optimized out"
during newer updates. However a look at a newer
manual under "Boot Processes" showed:
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset."
> My logic analyzer trace dumps show SDRAM
> initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while
> DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is
> not stable at all and I
> think that is part of the problem. This seems like a
> pretty egregious
> error both in documentation and implementation. I
> wouldn't expect to see
> something like this from TI. I keep hoping that I'm
> doing something wrong.
> I've scanned in the trace dumps and have them as
> PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to
> prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and
> hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from
> the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released
> (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000
> h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per
> SPRS106
>
=== message truncated ===
I have included my comments in line below.
mikedunn
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> We are using the 'C6205 in an embedded system that
> is not part of a PC.
> The 'C6205 is on an internal PCI bus used to
> communicate to other PCI
> peripherals. Consequently it takes too long to load
> the boot code into the
> DSP in host boot mode. The DSP application is larger
> than 64K and requires
> that the internal RAM be used as cache to support
> the required execution
> speed, so MAP 1 cannot be used.
>>mike>>Why can't Map1 be used?? I think that booting
the secondary loader into internal memory,
initializing and loading SDRAM, jumping to SDRAM and
then enabling 'cache mode' is the way to go. Even if
your original plan of booting to SDRAM worked, you
would be stuck with less than optimum EMIF
initialization. > That leaves MAP 0
> boot from flash as the
> best possible option for us. After all, it is an
> advertised option...
> I performed the following experiments in an attempt
> to debug the SDRAM
> problem.
>
> 1.) Disable the FLASH ram so there is not code to
> fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is
> read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected
> without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN
> is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh
> enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or
> greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625
> u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else
> is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we
> can 'peek and poke'
> into SDRAM. The memory seems fully functional and
> stable.
>
> 5.) Disconnect the emulator via CCS, power down the
> system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the
> push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct.
> It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see
> an immediate problem. > The secondary bootloader code has not been correctly
> copied into the
> SDRAM. Many instructions are just fine, but some
> instructions appear to
> have gotten a few bits flipped. This, of course, is
> a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>>mike>>Please forgive my ignorance - What is an
"EJTAG reset"?? I am not accustomed to seeing 'EJTAG'
in relation to TI.
>
> 10.) We can see the instructions in SDRAM change to
> the correct values.
> They are nicely highlighted in red by CCS. The code
> boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I
> have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I
> have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is
> being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded
> by the combination of
> SPRS106E and SPRU642.
>>mike>>I know. My comment was in relation to the
possibility that some of the info got "optimized out"
during newer updates. However a look at a newer
manual under "Boot Processes" showed:
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset."
> My logic analyzer trace dumps show SDRAM
> initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while
> DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is
> not stable at all and I
> think that is part of the problem. This seems like a
> pretty egregious
> error both in documentation and implementation. I
> wouldn't expect to see
> something like this from TI. I keep hoping that I'm
> doing something wrong.
> I've scanned in the trace dumps and have them as
> PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to
> prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and
> hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from
> the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released
> (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000
> h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per
> SPRS106
>
=== message truncated ===
Reply by ●October 12, 20052005-10-12
Joe-
> We are using the 'C6205 in an embedded system that is not part of a PC.
> The 'C6205 is on an internal PCI bus used to communicate to other PCI
> peripherals. Consequently it takes too long to load the boot code into the
> DSP in host boot mode. The DSP application is larger than 64K and requires
> that the internal RAM be used as cache to support the required execution
> speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as the
> best possible option for us. After all, it is an advertised option...
> I performed the following experiments in an attempt to debug the SDRAM
> problem.
I think you may be making this too hard. Can you boot a small amount of code via PCI
at boot-time, then once PCI bus stablizes and everybody is playing nicely and
quietly, then have the DSP code signal the PCI host to download the rest of the
code? Or just have the PCI host wait a while?
-Jeff
>
> 1.) Disable the FLASH ram so there is not code to fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625 u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we can 'peek and poke'
> into SDRAM. The memory seems fully functional and stable.
>
> 5.) Disconnect the emulator via CCS, power down the system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct. It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see an immediate problem.
>
> The secondary bootloader code has not been correctly copied into the
> SDRAM. Many instructions are just fine, but some instructions appear to
> have gotten a few bits flipped. This, of course, is a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>
> 10.) We can see the instructions in SDRAM change to the correct values.
> They are nicely highlighted in red by CCS. The code boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded by the combination of
> SPRS106E and SPRU642.
> My logic analyzer trace dumps show SDRAM initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is not stable at all and I
> think that is part of the problem. This seems like a pretty egregious
> error both in documentation and implementation. I wouldn't expect to see
> something like this from TI. I keep hoping that I'm doing something wrong.
> I've scanned in the trace dumps and have them as PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe
>
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000 h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per SPRS106
> > and SPRU642.
> >
> > I am beginning to question the accuracy of the TI
> > documentation.
> >
> > To better understand the boot process, I loaded a
> > version of test code
> > that is compiled for MAP 1 and internal RAM.
> >
> > The analyzer shows the processor reading from ROM
> > and loading internal RAM
> > (MAP 1) while the RESET pin is asserted (low). The
> > correct boot mode
> > information of 0 x 0880_016D h is placed on the bus
> > after RESET is
> > asserted. The ROM chip enable falls, and the
> > address begins to increment
> > as the bytes used to build the first instruction are
> > read from the ROM
> > while RESET is still asserted.
> >
> > For the DSP to 'know' that the boot mode is MAP 1
> > using an 8 bit ROM, it
> > must have read the boot mode pins some time after
> > the reset line was
> > asserted but before the ROM was chip enabled.
> >
> > I have also captured a sequence showing PCI BOOT. In
> > this case the chip
> > enable for the ROM does NOT become active. This is
> > to be expected for PCI
> > boot because the load will be coming through the PCI
> > resource. However, it
> > indicates again that the DSP has read the value of 0
> > x 0880 0167 h from
> > the data bus almost immediately after the RESET line
> > is asserted.
> >
> > This is not the sequence described by the TI doc's.
> > SPRU642 describes the
> > ROM boot process as: " The program located in
> > external ROM is copied to
> > address 0 by the DMA controller. Although the boot
> > process begins when the
> > device is released from external reset, this
> > transfer occurs while the CPU
> > is internally stalled." The RESET signal timing
> > shown in SPRS106E further
> > indicates that there should be no external bus
> > activity until after RESET
> > is released and the boot configuration is detected
> > by the rising edge of
> > reset.
> >
> > Has anyone ever successfully booted a C6205 into MAP
> > 0 from an 8 bit ROM
> > to SDRAM located on CE0 at 0 x 0000_0000 h?
> >
> > Has anyone else seen hardware boot loader activity
> > on the C6205 EMIF while
> > RESET is still asserted?
>
> It has been some time since I worked with boot issues
> on a 620x/6701 device. Two things that I can say for
> certain - [1] the 621x/671x/641x devices behave very
> differently than 620x/6701 device WRT booting and [2]
> the documents to which you refer accurately describe
> the 621x/671x/641x device boot behavior.
>
> I have seen systems that operated in various boot
> modes, but the only ones that I have seen that begin
> execution from SDRAM are those that operate in host
> boot mode. If I was in your situation, I would go to
> plan B and use a two level boot process. Go ahead and
> boot to internal RAM and then intialize the EMIF and
> copy the ROM to SDRAM. Although the process is a bit
> slower, the actual time from the rising edge of Reset
> should be close to the "advertised boot time" from the
> rising edge of Reset.
>
> News flash -
> I just refered to spru190a [1997 hard copy] and found
> the following -
> "Although the boot process begins when the device is
> released from external reset, this transfer occurs
> while the CPU is internally held in reset."
>
> One possibility is that the 'default SDRAM timing'
> that is hardwired into the device may not be
> compatible with contemporary SDRAM devices.
>
> Another thought is that the reset pulse is too long
> [that's a switch] and causing some undersirable side
> effect [killing refresh??]
>
> RE:
> "I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run."
>
> How did you do this?? Did you configure the EMIF
> first??
>
> mikedunn >
> We are using the 'C6205 in an embedded system that is not part of a PC.
> The 'C6205 is on an internal PCI bus used to communicate to other PCI
> peripherals. Consequently it takes too long to load the boot code into the
> DSP in host boot mode. The DSP application is larger than 64K and requires
> that the internal RAM be used as cache to support the required execution
> speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as the
> best possible option for us. After all, it is an advertised option...
> I performed the following experiments in an attempt to debug the SDRAM
> problem.
I think you may be making this too hard. Can you boot a small amount of code via PCI
at boot-time, then once PCI bus stablizes and everybody is playing nicely and
quietly, then have the DSP code signal the PCI host to download the rest of the
code? Or just have the PCI host wait a while?
-Jeff
>
> 1.) Disable the FLASH ram so there is not code to fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625 u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we can 'peek and poke'
> into SDRAM. The memory seems fully functional and stable.
>
> 5.) Disconnect the emulator via CCS, power down the system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct. It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see an immediate problem.
>
> The secondary bootloader code has not been correctly copied into the
> SDRAM. Many instructions are just fine, but some instructions appear to
> have gotten a few bits flipped. This, of course, is a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>
> 10.) We can see the instructions in SDRAM change to the correct values.
> They are nicely highlighted in red by CCS. The code boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded by the combination of
> SPRS106E and SPRU642.
> My logic analyzer trace dumps show SDRAM initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is not stable at all and I
> think that is part of the problem. This seems like a pretty egregious
> error both in documentation and implementation. I wouldn't expect to see
> something like this from TI. I keep hoping that I'm doing something wrong.
> I've scanned in the trace dumps and have them as PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe
>
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000 h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per SPRS106
> > and SPRU642.
> >
> > I am beginning to question the accuracy of the TI
> > documentation.
> >
> > To better understand the boot process, I loaded a
> > version of test code
> > that is compiled for MAP 1 and internal RAM.
> >
> > The analyzer shows the processor reading from ROM
> > and loading internal RAM
> > (MAP 1) while the RESET pin is asserted (low). The
> > correct boot mode
> > information of 0 x 0880_016D h is placed on the bus
> > after RESET is
> > asserted. The ROM chip enable falls, and the
> > address begins to increment
> > as the bytes used to build the first instruction are
> > read from the ROM
> > while RESET is still asserted.
> >
> > For the DSP to 'know' that the boot mode is MAP 1
> > using an 8 bit ROM, it
> > must have read the boot mode pins some time after
> > the reset line was
> > asserted but before the ROM was chip enabled.
> >
> > I have also captured a sequence showing PCI BOOT. In
> > this case the chip
> > enable for the ROM does NOT become active. This is
> > to be expected for PCI
> > boot because the load will be coming through the PCI
> > resource. However, it
> > indicates again that the DSP has read the value of 0
> > x 0880 0167 h from
> > the data bus almost immediately after the RESET line
> > is asserted.
> >
> > This is not the sequence described by the TI doc's.
> > SPRU642 describes the
> > ROM boot process as: " The program located in
> > external ROM is copied to
> > address 0 by the DMA controller. Although the boot
> > process begins when the
> > device is released from external reset, this
> > transfer occurs while the CPU
> > is internally stalled." The RESET signal timing
> > shown in SPRS106E further
> > indicates that there should be no external bus
> > activity until after RESET
> > is released and the boot configuration is detected
> > by the rising edge of
> > reset.
> >
> > Has anyone ever successfully booted a C6205 into MAP
> > 0 from an 8 bit ROM
> > to SDRAM located on CE0 at 0 x 0000_0000 h?
> >
> > Has anyone else seen hardware boot loader activity
> > on the C6205 EMIF while
> > RESET is still asserted?
>
> It has been some time since I worked with boot issues
> on a 620x/6701 device. Two things that I can say for
> certain - [1] the 621x/671x/641x devices behave very
> differently than 620x/6701 device WRT booting and [2]
> the documents to which you refer accurately describe
> the 621x/671x/641x device boot behavior.
>
> I have seen systems that operated in various boot
> modes, but the only ones that I have seen that begin
> execution from SDRAM are those that operate in host
> boot mode. If I was in your situation, I would go to
> plan B and use a two level boot process. Go ahead and
> boot to internal RAM and then intialize the EMIF and
> copy the ROM to SDRAM. Although the process is a bit
> slower, the actual time from the rising edge of Reset
> should be close to the "advertised boot time" from the
> rising edge of Reset.
>
> News flash -
> I just refered to spru190a [1997 hard copy] and found
> the following -
> "Although the boot process begins when the device is
> released from external reset, this transfer occurs
> while the CPU is internally held in reset."
>
> One possibility is that the 'default SDRAM timing'
> that is hardwired into the device may not be
> compatible with contemporary SDRAM devices.
>
> Another thought is that the reset pulse is too long
> [that's a switch] and causing some undersirable side
> effect [killing refresh??]
>
> RE:
> "I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run."
>
> How did you do this?? Did you configure the EMIF
> first??
>
> mikedunn >
Reply by ●October 13, 20052005-10-13
Mike,
Our intent was to load the secondary boot loader to MAP0, SDRAM, which
would then load the app to SDRAM. The app then tweaks the SDRAM EMIF
settings for optimum speed and executes in "cache mode". I was not aware
that you can enable "cache mode" once the DSP has read the boot mode as
"internal". Do you know which register would contain this function? I will
scan the doc's.
When I talk about "EJTAG RESET", I am referring to the reset CPU that is
sent from CCS using the background debug emulator. The sequence is
<connect>, <CPU reset>, <disconnect>. (The hardware mechanism used to
support the emulator function is EJTAG. Sorry, you may have guessed I'm
really a hardware guy). Performing this sequence is the only way I can
capture the SDRAM command initialization (DCAB, REFR x 8, MRS) occurring
with RESET de-asserted. It is also the only way I have been able to get
this boot mode running.
Again, my observations with the logic analyzer conflict with the TI doc's.
I have tried two different makes & models of analyzer, had others verify
my connections, buzzed out the circuit board with a meter to cross check
against the schematic, and double checked the signals with an
oscilloscope. I am not able to capture SDRAM init and load during RESET
high unless I intervene with CCS.
I need to get the application code loaded from ROM into SDRAM and the DSP
executing out of cache. At this point, I'll try anything that may get us
there.
Joe
Mike Dunn <mike-dunn@mike...>
10/12/2005 05:39 PM
To
Joe.Futey@Joe....
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe,
I have included my comments in line below.
mikedunn
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> We are using the 'C6205 in an embedded system that
> is not part of a PC.
> The 'C6205 is on an internal PCI bus used to
> communicate to other PCI
> peripherals. Consequently it takes too long to load
> the boot code into the
> DSP in host boot mode. The DSP application is larger
> than 64K and requires
> that the internal RAM be used as cache to support
> the required execution
> speed, so MAP 1 cannot be used.
>>mike>>Why can't Map1 be used?? I think that booting
the secondary loader into internal memory,
initializing and loading SDRAM, jumping to SDRAM and
then enabling 'cache mode' is the way to go. Even if
your original plan of booting to SDRAM worked, you
would be stuck with less than optimum EMIF
initialization. > That leaves MAP 0
> boot from flash as the
> best possible option for us. After all, it is an
> advertised option...
> I performed the following experiments in an attempt
> to debug the SDRAM
> problem.
>
> 1.) Disable the FLASH ram so there is not code to
> fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is
> read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected
> without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN
> is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh
> enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or
> greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625
> u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else
> is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we
> can 'peek and poke'
> into SDRAM. The memory seems fully functional and
> stable.
>
> 5.) Disconnect the emulator via CCS, power down the
> system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the
> push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct.
> It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see
> an immediate problem. > The secondary bootloader code has not been correctly
> copied into the
> SDRAM. Many instructions are just fine, but some
> instructions appear to
> have gotten a few bits flipped. This, of course, is
> a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>>mike>>Please forgive my ignorance - What is an
"EJTAG reset"?? I am not accustomed to seeing 'EJTAG'
in relation to TI.
>
> 10.) We can see the instructions in SDRAM change to
> the correct values.
> They are nicely highlighted in red by CCS. The code
> boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I
> have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I
> have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is
> being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded
> by the combination of
> SPRS106E and SPRU642.
>>mike>>I know. My comment was in relation to the
possibility that some of the info got "optimized out"
during newer updates. However a look at a newer
manual under "Boot Processes" showed:
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset."
> My logic analyzer trace dumps show SDRAM
> initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while
> DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is
> not stable at all and I
> think that is part of the problem. This seems like a
> pretty egregious
> error both in documentation and implementation. I
> wouldn't expect to see
> something like this from TI. I keep hoping that I'm
> doing something wrong.
> I've scanned in the trace dumps and have them as
> PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to
> prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and
> hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from
> the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released
> (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000
> h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per
> SPRS106
>
=== message truncated ===
Our intent was to load the secondary boot loader to MAP0, SDRAM, which
would then load the app to SDRAM. The app then tweaks the SDRAM EMIF
settings for optimum speed and executes in "cache mode". I was not aware
that you can enable "cache mode" once the DSP has read the boot mode as
"internal". Do you know which register would contain this function? I will
scan the doc's.
When I talk about "EJTAG RESET", I am referring to the reset CPU that is
sent from CCS using the background debug emulator. The sequence is
<connect>, <CPU reset>, <disconnect>. (The hardware mechanism used to
support the emulator function is EJTAG. Sorry, you may have guessed I'm
really a hardware guy). Performing this sequence is the only way I can
capture the SDRAM command initialization (DCAB, REFR x 8, MRS) occurring
with RESET de-asserted. It is also the only way I have been able to get
this boot mode running.
Again, my observations with the logic analyzer conflict with the TI doc's.
I have tried two different makes & models of analyzer, had others verify
my connections, buzzed out the circuit board with a meter to cross check
against the schematic, and double checked the signals with an
oscilloscope. I am not able to capture SDRAM init and load during RESET
high unless I intervene with CCS.
I need to get the application code loaded from ROM into SDRAM and the DSP
executing out of cache. At this point, I'll try anything that may get us
there.
Joe
Mike Dunn <mike-dunn@mike...>
10/12/2005 05:39 PM
To
Joe.Futey@Joe....
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe,
I have included my comments in line below.
mikedunn
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> We are using the 'C6205 in an embedded system that
> is not part of a PC.
> The 'C6205 is on an internal PCI bus used to
> communicate to other PCI
> peripherals. Consequently it takes too long to load
> the boot code into the
> DSP in host boot mode. The DSP application is larger
> than 64K and requires
> that the internal RAM be used as cache to support
> the required execution
> speed, so MAP 1 cannot be used.
>>mike>>Why can't Map1 be used?? I think that booting
the secondary loader into internal memory,
initializing and loading SDRAM, jumping to SDRAM and
then enabling 'cache mode' is the way to go. Even if
your original plan of booting to SDRAM worked, you
would be stuck with less than optimum EMIF
initialization. > That leaves MAP 0
> boot from flash as the
> best possible option for us. After all, it is an
> advertised option...
> I performed the following experiments in an attempt
> to debug the SDRAM
> problem.
>
> 1.) Disable the FLASH ram so there is not code to
> fetch.
> 2.) Let the DSP come out of reset so the BOOTMODE is
> read and the EMIF
> defaults are set.
> 3.) Using the EJTAG XDS510 USB emulator connected
> without a GEL file and
> read the EMIF configuration:
>
> GBCTL 0x 0000 3778 h
> 0000 3 = reserved
> 7 = ardy, hold, holda are logic high, should be ok
> 7 = SDCEN is 1 (SDCLK enabled for SDRAM use), SSCEN
> is 1 (SSCLK enabled),
> CLK1EN is 1 (CLKOUT1 enabled)
> 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> at address 0x0000
> 0000h)
>
> SDCTL 0x 0788 F000 h
> 0000 = reserved
> 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM refresh
> enabled), INIT is 1,
> (undefined for reads)
> 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> greater).
> 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> greater).
> F= TRC is 1111 = 160 ns (part requires 70 ns or
> greater).
> 000 = reserved
>
> SDTIM 0x 0003 B040 h
> 00 = reserved
> 03B = counter value (always changing)
> 040 = refresh period = 640 ns (part requires 15.625
> u sec or less)
>
> CECTL0 0x FFFF 3F33 h
> xxxx xx3x = M-Type is 32 bit SDRAM. Everything else
> is "don't care"
>
> O.K., everything looks fine to me at this point.
>
> 4.) Using the XDS510 and CCS (with no GEL file) we
> can 'peek and poke'
> into SDRAM. The memory seems fully functional and
> stable.
>
> 5.) Disconnect the emulator via CCS, power down the
> system and enable the
> flash ram.
>
> 6.) Power up the system, reset the DSP using the
> push button, connect with
> CCS via the XDS510.
>
> 7.) Verify that the EMIF configuration is correct.
> It is the same as
> above.
>
> 8.) Inspecting the contents of the SDRAM, we can see
> an immediate problem. > The secondary bootloader code has not been correctly
> copied into the
> SDRAM. Many instructions are just fine, but some
> instructions appear to
> have gotten a few bits flipped. This, of course, is
> a very bad thing that
> has lead the secondary boot loader to crash.
>
> 9.) Using CCS and the XDS510, issue an EJTAG reset.
>>mike>>Please forgive my ignorance - What is an
"EJTAG reset"?? I am not accustomed to seeing 'EJTAG'
in relation to TI.
>
> 10.) We can see the instructions in SDRAM change to
> the correct values.
> They are nicely highlighted in red by CCS. The code
> boots and runs
> normally.
> The problem persists at 20 MHz as well as 200 MHz. I
> have changed the boot
> mode switches to bypass the PLL and run at 20 MHz. I
> have re-verified the
> SDRAM timing using 20 MHz defaults and it is O.K.
> There is no operating system present. The board is
> being used stand alone,
> not in any PC.
> TI - DSP help says that SPRU190A has been superseded
> by the combination of
> SPRS106E and SPRU642.
>>mike>>I know. My comment was in relation to the
possibility that some of the info got "optimized out"
during newer updates. However a look at a newer
manual under "Boot Processes" showed:
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset."
> My logic analyzer trace dumps show SDRAM
> initialization, fetches from the
> ROM and instruction writes to SDRAM occurring while
> DSP RESET is asserted.
> The EMIF SDRAM clock during the initialization is
> not stable at all and I
> think that is part of the problem. This seems like a
> pretty egregious
> error both in documentation and implementation. I
> wouldn't expect to see
> something like this from TI. I keep hoping that I'm
> doing something wrong.
> I've scanned in the trace dumps and have them as
> PDF's if you would like
> to see them.
> Thanks for the prompt response.
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> Sent by: c6x@c6x@...
> 10/12/2005 03:45 PM
>
> To
> joe.futey@joe...., c6x@c6x@...
> cc
>
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Hello Joe,
>
> Please see comments below.
>
> --- joe.futey@joe.... wrote:
>
> > All,
> >
> > I am using the eInfochips EVM6205 board to
> prototype
> > a C6205 embedded
> > system.
> >
> > My system must use the MAP 0 memory map which
> > requires booting from SDRAM
> > located on CE0 at 0 x 0000_0000 h.
> >
> > I have been unable to get the EVM6205 to boot
> > successfully into MAP 0
> > using the boot mode switches from power up and
> hard
> > reset. The contents of
> > the SDRAM are corrupted as they are loaded from
> the
> > ROM by the hardware
> > boot loader. I can use the JTAG emulator to reset
> > the DSP core and rerun
> > the hardware boot loader. This corrects the
> > corrupted SDRAM locations and
> > allows the DSP to run.
> >
> > When I connected a logic analyzer to capture both
> > SDRAM accesses and ROM
> > accesses. I saw some very puzzling things...
> >
> > The some type of SDRAM initialization is occurring
> > sometime after RESET is
> > asserted (goes low), and before it is released
> (goes
> > high). The DSP then
> > reads the ROM starting from address 0 x 0100_0000
> h.
> > It looks like the
> > correct byte values are read. Next, the DSP writes
> > what looks like the
> > correct values into the SDRAM. The RESET signal is
> > still asserted during
> > this entire time !
> >
> > TI DSP help stated that this is not possible.
> > Hardware boot loading does
> > not occur until after RESET is released per
> SPRS106
>
=== message truncated ===
Reply by ●October 13, 20052005-10-13
Jeff,
The PCI bus is totally embedded. The other devices on the bus do not have
the memory resources to store the application code. The only path in is
through a USB 1.1 controller which would make the application download
time in excess of 20 seconds (too slow of a boot for our customers).
The application needs to be loaded into SDRAM because of it's size, and
the DSP executing from cache to achieve performance. Using the ROM seems
to be the only way to keep the boot time within customer expectations.
Joe
Jeff Brower <jbrower@jbro...>
10/12/2005 06:24 PM
To
Joe Futey <joe.futey@joe....>
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe-
> We are using the 'C6205 in an embedded system that is not part of a PC.
> The 'C6205 is on an internal PCI bus used to communicate to other PCI
> peripherals. Consequently it takes too long to load the boot code into
the
> DSP in host boot mode. The DSP application is larger than 64K and
requires
> that the internal RAM be used as cache to support the required execution
> speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
the
> best possible option for us. After all, it is an advertised option...
> I performed the following experiments in an attempt to debug the SDRAM
> problem.
I think you may be making this too hard. Can you boot a small amount of
code via PCI
at boot-time, then once PCI bus stablizes and everybody is playing nicely
and
quietly, then have the DSP code signal the PCI host to download the rest
of the
code? Or just have the PCI host wait a while?
-Jeff
The PCI bus is totally embedded. The other devices on the bus do not have
the memory resources to store the application code. The only path in is
through a USB 1.1 controller which would make the application download
time in excess of 20 seconds (too slow of a boot for our customers).
The application needs to be loaded into SDRAM because of it's size, and
the DSP executing from cache to achieve performance. Using the ROM seems
to be the only way to keep the boot time within customer expectations.
Joe
Jeff Brower <jbrower@jbro...>
10/12/2005 06:24 PM
To
Joe Futey <joe.futey@joe....>
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe-
> We are using the 'C6205 in an embedded system that is not part of a PC.
> The 'C6205 is on an internal PCI bus used to communicate to other PCI
> peripherals. Consequently it takes too long to load the boot code into
the
> DSP in host boot mode. The DSP application is larger than 64K and
requires
> that the internal RAM be used as cache to support the required execution
> speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
the
> best possible option for us. After all, it is an advertised option...
> I performed the following experiments in an attempt to debug the SDRAM
> problem.
I think you may be making this too hard. Can you boot a small amount of
code via PCI
at boot-time, then once PCI bus stablizes and everybody is playing nicely
and
quietly, then have the DSP code signal the PCI host to download the rest
of the
code? Or just have the PCI host wait a while?
-Jeff
Reply by ●October 13, 20052005-10-13
Joe-
> The PCI bus is totally embedded. The other devices on the bus do not have
> the memory resources to store the application code. The only path in is
> through a USB 1.1 controller which would make the application download
> time in excess of 20 seconds (too slow of a boot for our customers).
>
> The application needs to be loaded into SDRAM because of it's size, and
> the DSP executing from cache to achieve performance. Using the ROM seems
> to be the only way to keep the boot time within customer expectations.
Ya Ok. I was thinking there might be another processor on this board.
You don't have a CPLD on the board? A CPLD could read the Flash and download to DSP
HPI at boot-time, then change the config R and reset the DSP into PCI mode.
-Jeff
> Jeff Brower <jbrower@jbro...>
> 10/12/2005 06:24 PM
>
> To
> Joe Futey <joe.futey@joe....>
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Joe-
>
> > We are using the 'C6205 in an embedded system that is not part of a PC.
> > The 'C6205 is on an internal PCI bus used to communicate to other PCI
> > peripherals. Consequently it takes too long to load the boot code into
> the
> > DSP in host boot mode. The DSP application is larger than 64K and
> requires
> > that the internal RAM be used as cache to support the required execution
> > speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
> the
> > best possible option for us. After all, it is an advertised option...
> > I performed the following experiments in an attempt to debug the SDRAM
> > problem.
>
> I think you may be making this too hard. Can you boot a small amount of
> code via PCI
> at boot-time, then once PCI bus stablizes and everybody is playing nicely
> and
> quietly, then have the DSP code signal the PCI host to download the rest
> of the
> code? Or just have the PCI host wait a while?
>
> -Jeff
> The PCI bus is totally embedded. The other devices on the bus do not have
> the memory resources to store the application code. The only path in is
> through a USB 1.1 controller which would make the application download
> time in excess of 20 seconds (too slow of a boot for our customers).
>
> The application needs to be loaded into SDRAM because of it's size, and
> the DSP executing from cache to achieve performance. Using the ROM seems
> to be the only way to keep the boot time within customer expectations.
Ya Ok. I was thinking there might be another processor on this board.
You don't have a CPLD on the board? A CPLD could read the Flash and download to DSP
HPI at boot-time, then change the config R and reset the DSP into PCI mode.
-Jeff
> Jeff Brower <jbrower@jbro...>
> 10/12/2005 06:24 PM
>
> To
> Joe Futey <joe.futey@joe....>
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Joe-
>
> > We are using the 'C6205 in an embedded system that is not part of a PC.
> > The 'C6205 is on an internal PCI bus used to communicate to other PCI
> > peripherals. Consequently it takes too long to load the boot code into
> the
> > DSP in host boot mode. The DSP application is larger than 64K and
> requires
> > that the internal RAM be used as cache to support the required execution
> > speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
> the
> > best possible option for us. After all, it is an advertised option...
> > I performed the following experiments in an attempt to debug the SDRAM
> > problem.
>
> I think you may be making this too hard. Can you boot a small amount of
> code via PCI
> at boot-time, then once PCI bus stablizes and everybody is playing nicely
> and
> quietly, then have the DSP code signal the PCI host to download the rest
> of the
> code? Or just have the PCI host wait a while?
>
> -Jeff
Reply by ●October 13, 20052005-10-13
Jeff,
I've got an FPGA on board, but the 'C6205 does not have a HPI only the
PCI. Unless I'm mistaken it's always a PCI bus. There is no way to
reconfigure it. The FPGA is on the DSP's bus anyway, not the PCI bus (it
glues the DSP to another proprietary bus structure). I'm exploring the
idea of placing the secondary bootloader code in the FPGA, but this
approach is beginning to look like a Rube Goldberg mechanism as I may have
to dynamically re-assign chip selects after the secondary bootloader is
done loading the application... Looks like the timing could be tricky.
Joe
Jeff Brower <jbrower@jbro...>
10/13/2005 10:59 AM
To
Joe Futey <joe.futey@joe....>
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe-
> The PCI bus is totally embedded. The other devices on the bus do not
have
> the memory resources to store the application code. The only path in is
> through a USB 1.1 controller which would make the application download
> time in excess of 20 seconds (too slow of a boot for our customers).
>
> The application needs to be loaded into SDRAM because of it's size, and
> the DSP executing from cache to achieve performance. Using the ROM seems
> to be the only way to keep the boot time within customer expectations.
Ya Ok. I was thinking there might be another processor on this board.
You don't have a CPLD on the board? A CPLD could read the Flash and
download to DSP
HPI at boot-time, then change the config R and reset the DSP into PCI
mode.
-Jeff
> Jeff Brower <jbrower@jbro...>
> 10/12/2005 06:24 PM
>
> To
> Joe Futey <joe.futey@joe....>
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Joe-
>
> > We are using the 'C6205 in an embedded system that is not part of a
PC.
> > The 'C6205 is on an internal PCI bus used to communicate to other PCI
> > peripherals. Consequently it takes too long to load the boot code into
> the
> > DSP in host boot mode. The DSP application is larger than 64K and
> requires
> > that the internal RAM be used as cache to support the required
execution
> > speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
> the
> > best possible option for us. After all, it is an advertised option...
> > I performed the following experiments in an attempt to debug the SDRAM
> > problem.
>
> I think you may be making this too hard. Can you boot a small amount of
> code via PCI
> at boot-time, then once PCI bus stablizes and everybody is playing
nicely
> and
> quietly, then have the DSP code signal the PCI host to download the rest
> of the
> code? Or just have the PCI host wait a while?
>
> -Jeff
I've got an FPGA on board, but the 'C6205 does not have a HPI only the
PCI. Unless I'm mistaken it's always a PCI bus. There is no way to
reconfigure it. The FPGA is on the DSP's bus anyway, not the PCI bus (it
glues the DSP to another proprietary bus structure). I'm exploring the
idea of placing the secondary bootloader code in the FPGA, but this
approach is beginning to look like a Rube Goldberg mechanism as I may have
to dynamically re-assign chip selects after the secondary bootloader is
done loading the application... Looks like the timing could be tricky.
Joe
Jeff Brower <jbrower@jbro...>
10/13/2005 10:59 AM
To
Joe Futey <joe.futey@joe....>
cc
c6x@c6x@...
Subject
Re: [c6x] C6205 hardware boot loader / SDRAM problem
Joe-
> The PCI bus is totally embedded. The other devices on the bus do not
have
> the memory resources to store the application code. The only path in is
> through a USB 1.1 controller which would make the application download
> time in excess of 20 seconds (too slow of a boot for our customers).
>
> The application needs to be loaded into SDRAM because of it's size, and
> the DSP executing from cache to achieve performance. Using the ROM seems
> to be the only way to keep the boot time within customer expectations.
Ya Ok. I was thinking there might be another processor on this board.
You don't have a CPLD on the board? A CPLD could read the Flash and
download to DSP
HPI at boot-time, then change the config R and reset the DSP into PCI
mode.
-Jeff
> Jeff Brower <jbrower@jbro...>
> 10/12/2005 06:24 PM
>
> To
> Joe Futey <joe.futey@joe....>
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Joe-
>
> > We are using the 'C6205 in an embedded system that is not part of a
PC.
> > The 'C6205 is on an internal PCI bus used to communicate to other PCI
> > peripherals. Consequently it takes too long to load the boot code into
> the
> > DSP in host boot mode. The DSP application is larger than 64K and
> requires
> > that the internal RAM be used as cache to support the required
execution
> > speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash as
> the
> > best possible option for us. After all, it is an advertised option...
> > I performed the following experiments in an attempt to debug the SDRAM
> > problem.
>
> I think you may be making this too hard. Can you boot a small amount of
> code via PCI
> at boot-time, then once PCI bus stablizes and everybody is playing
nicely
> and
> quietly, then have the DSP code signal the PCI host to download the rest
> of the
> code? Or just have the PCI host wait a while?
>
> -Jeff
Reply by ●October 13, 20052005-10-13
Joe,
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> Our intent was to load the secondary boot loader to
> MAP0, SDRAM, which
> would then load the app to SDRAM. The app then
> tweaks the SDRAM EMIF
> settings for optimum speed and executes in "cache
> mode".
mike>>I may just be paranoid - reprogramming the EMIF
while executing code controlled by the EMIF seems like
an opportunity for "hiccups"
>I was not aware
> that you can enable "cache mode" once the DSP has
> read the boot mode as
> "internal".
mike>>I believe that is the only way that you can
change the cache mode. There is a snippet of code to
do it in the manual that refers to "internal memory".
Search for 'PCC'.
>Do you know which register would contain
> this function?
mike>> The register is the CSR - the field is called
PCC. You can modify it from CCS by changing the
register called PCC. You can select enable, disable,
freeze and bypass modes.
>I will
> scan the doc's.
>
> When I talk about "EJTAG RESET", I am referring to
> the reset CPU that is
> sent from CCS using the background debug emulator.
> The sequence is
> <connect>, <CPU reset>, <disconnect>. (The hardware
> mechanism used to
> support the emulator function is EJTAG.
mike>> I thought that was what you were referring to,
but as I read it from a literal hardware view, it
could have been interpreted as 'JTAG reset' [a.k.a.
nTRST] that is performed by a TI utility called
'xdsreset'.
>Sorry, you
> may have guessed I'm
> really a hardware guy). Performing this sequence is
> the only way I can
> capture the SDRAM command initialization (DCAB, REFR
> x 8, MRS) occurring
> with RESET de-asserted. It is also the only way I
> have been able to get
> this boot mode running.
>
> Again, my observations with the logic analyzer
> conflict with the TI doc's.
mike>> Actually they seem to 'weasel-word' around it
by not including the copy as part of the boot process.
Again from their docs -
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset." > I have tried two different makes & models of
> analyzer, had others verify
> my connections, buzzed out the circuit board with a
> meter to cross check
> against the schematic, and double checked the
> signals with an
> oscilloscope. I am not able to capture SDRAM init
> and load during RESET
> high unless I intervene with CCS.
>
> I need to get the application code loaded from ROM
> into SDRAM and the DSP
> executing out of cache. At this point, I'll try
> anything that may get us
> there.
I think that you are about to zero in on a solution.
Keep us posted on the saga - it may be a valuable
learning experience for some of the 'lurkers' out
there.
mikedunn
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> 10/12/2005 05:39 PM
>
> To
> Joe.Futey@Joe....
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Joe,
>
> I have included my comments in line below.
>
> mikedunn
>
> --- Joe.Futey@Joe.... wrote:
>
> > Mike,
> >
> > We are using the 'C6205 in an embedded system that
> > is not part of a PC.
> > The 'C6205 is on an internal PCI bus used to
> > communicate to other PCI
> > peripherals. Consequently it takes too long to
> load
> > the boot code into the
> > DSP in host boot mode. The DSP application is
> larger
> > than 64K and requires
> > that the internal RAM be used as cache to support
> > the required execution
> > speed, so MAP 1 cannot be used.
>
> >>mike>>Why can't Map1 be used?? I think that
> booting
> the secondary loader into internal memory,
> initializing and loading SDRAM, jumping to SDRAM and
> then enabling 'cache mode' is the way to go. Even
> if
> your original plan of booting to SDRAM worked, you
> would be stuck with less than optimum EMIF
> initialization. > > That leaves MAP 0
> > boot from flash as the
> > best possible option for us. After all, it is an
> > advertised option...
> > I performed the following experiments in an
> attempt
> > to debug the SDRAM
> > problem.
> >
> > 1.) Disable the FLASH ram so there is not code to
> > fetch.
> > 2.) Let the DSP come out of reset so the BOOTMODE
> is
> > read and the EMIF
> > defaults are set.
> > 3.) Using the EJTAG XDS510 USB emulator connected
> > without a GEL file and
> > read the EMIF configuration:
> >
> > GBCTL 0x 0000 3778 h
> > 0000 3 = reserved
> > 7 = ardy, hold, holda are logic high, should be ok
> > 7 = SDCEN is 1 (SDCLK enabled for SDRAM use),
> SSCEN
> > is 1 (SSCLK enabled),
> > CLK1EN is 1 (CLKOUT1 enabled)
> > 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> > at address 0x0000
> > 0000h)
> >
> > SDCTL 0x 0788 F000 h
> > 0000 = reserved
> > 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM
> refresh
> > enabled), INIT is 1,
> > (undefined for reads)
> > 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> > greater).
> > 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> > greater).
> > F= TRC is 1111 = 160 ns (part requires 70 ns or
> > greater).
> > 000 = reserved
> >
> > SDTIM 0x 0003 B040 h
> > 00 = reserved
> > 03B = counter value (always changing)
> > 040 = refresh period = 640 ns (part requires
> 15.625
> > u sec or less)
> >
> > CECTL0 0x FFFF 3F33 h
> > xxxx xx3x = M-Type is 32 bit SDRAM. Everything
> else
> > is "don't care"
> >
> > O.K., everything looks fine to me at this point.
> >
> > 4.) Using the XDS510 and CCS (with no GEL file) we
> > can 'peek and poke'
> > into SDRAM. The memory seems fully functional and
> > stable.
> >
> > 5.) Disconnect the emulator via CCS, power down
> the
> > system and enable the
> > flash ram.
> >
> > 6.) Power up the system, reset the DSP using the
> > push button, connect with
> > CCS via the XDS510.
> >
> > 7.) Verify that the EMIF configuration is correct.
> > It is the same as
> > above.
> >
> > 8.) Inspecting the contents of the SDRAM, we can
> see
> > an immediate problem.
> >
> >
> > The secondary bootloader code has not been
> correctly
> > copied into the
> > SDRAM. Many instructions are just fine, but some
> > instructions appear to
> > have gotten a few bits flipped. This, of course,
> is
> > a very bad thing that
> > has lead the secondary boot loader to crash.
> >
> > 9.) Using CCS and the XDS510, issue an EJTAG
> reset.
>
> >>mike>>Please forgive my ignorance - What is an
> "EJTAG reset"?? I am not accustomed to seeing
> 'EJTAG'
> in relation to TI. === message truncated ===
--- Joe.Futey@Joe.... wrote:
> Mike,
>
> Our intent was to load the secondary boot loader to
> MAP0, SDRAM, which
> would then load the app to SDRAM. The app then
> tweaks the SDRAM EMIF
> settings for optimum speed and executes in "cache
> mode".
mike>>I may just be paranoid - reprogramming the EMIF
while executing code controlled by the EMIF seems like
an opportunity for "hiccups"
>I was not aware
> that you can enable "cache mode" once the DSP has
> read the boot mode as
> "internal".
mike>>I believe that is the only way that you can
change the cache mode. There is a snippet of code to
do it in the manual that refers to "internal memory".
Search for 'PCC'.
>Do you know which register would contain
> this function?
mike>> The register is the CSR - the field is called
PCC. You can modify it from CCS by changing the
register called PCC. You can select enable, disable,
freeze and bypass modes.
>I will
> scan the doc's.
>
> When I talk about "EJTAG RESET", I am referring to
> the reset CPU that is
> sent from CCS using the background debug emulator.
> The sequence is
> <connect>, <CPU reset>, <disconnect>. (The hardware
> mechanism used to
> support the emulator function is EJTAG.
mike>> I thought that was what you were referring to,
but as I read it from a literal hardware view, it
could have been interpreted as 'JTAG reset' [a.k.a.
nTRST] that is performed by a TI utility called
'xdsreset'.
>Sorry, you
> may have guessed I'm
> really a hardware guy). Performing this sequence is
> the only way I can
> capture the SDRAM command initialization (DCAB, REFR
> x 8, MRS) occurring
> with RESET de-asserted. It is also the only way I
> have been able to get
> this boot mode running.
>
> Again, my observations with the logic analyzer
> conflict with the TI doc's.
mike>> Actually they seem to 'weasel-word' around it
by not including the copy as part of the boot process.
Again from their docs -
"The program located in external ROM is copied to
address 0 by the DMA/EDMA controller. Although the
boot process begins when the device is released from
external reset, this transfer occurs while the CPU is
internally held in reset." > I have tried two different makes & models of
> analyzer, had others verify
> my connections, buzzed out the circuit board with a
> meter to cross check
> against the schematic, and double checked the
> signals with an
> oscilloscope. I am not able to capture SDRAM init
> and load during RESET
> high unless I intervene with CCS.
>
> I need to get the application code loaded from ROM
> into SDRAM and the DSP
> executing out of cache. At this point, I'll try
> anything that may get us
> there.
I think that you are about to zero in on a solution.
Keep us posted on the saga - it may be a valuable
learning experience for some of the 'lurkers' out
there.
mikedunn
>
> Joe >
> Mike Dunn <mike-dunn@mike...>
> 10/12/2005 05:39 PM
>
> To
> Joe.Futey@Joe....
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem >
> Joe,
>
> I have included my comments in line below.
>
> mikedunn
>
> --- Joe.Futey@Joe.... wrote:
>
> > Mike,
> >
> > We are using the 'C6205 in an embedded system that
> > is not part of a PC.
> > The 'C6205 is on an internal PCI bus used to
> > communicate to other PCI
> > peripherals. Consequently it takes too long to
> load
> > the boot code into the
> > DSP in host boot mode. The DSP application is
> larger
> > than 64K and requires
> > that the internal RAM be used as cache to support
> > the required execution
> > speed, so MAP 1 cannot be used.
>
> >>mike>>Why can't Map1 be used?? I think that
> booting
> the secondary loader into internal memory,
> initializing and loading SDRAM, jumping to SDRAM and
> then enabling 'cache mode' is the way to go. Even
> if
> your original plan of booting to SDRAM worked, you
> would be stuck with less than optimum EMIF
> initialization. > > That leaves MAP 0
> > boot from flash as the
> > best possible option for us. After all, it is an
> > advertised option...
> > I performed the following experiments in an
> attempt
> > to debug the SDRAM
> > problem.
> >
> > 1.) Disable the FLASH ram so there is not code to
> > fetch.
> > 2.) Let the DSP come out of reset so the BOOTMODE
> is
> > read and the EMIF
> > defaults are set.
> > 3.) Using the EJTAG XDS510 USB emulator connected
> > without a GEL file and
> > read the EMIF configuration:
> >
> > GBCTL 0x 0000 3778 h
> > 0000 3 = reserved
> > 7 = ardy, hold, holda are logic high, should be ok
> > 7 = SDCEN is 1 (SDCLK enabled for SDRAM use),
> SSCEN
> > is 1 (SSCLK enabled),
> > CLK1EN is 1 (CLKOUT1 enabled)
> > 8 = CLK2EN is 1 (CLKOUT2 enabled), MAP is 0 (SDRAM
> > at address 0x0000
> > 0000h)
> >
> > SDCTL 0x 0788 F000 h
> > 0000 = reserved
> > 7 = SDWID is 1 (2x16 bit), RFEN is 1 (SDRAM
> refresh
> > enabled), INIT is 1,
> > (undefined for reads)
> > 8 = TRCD is 1000 = 90 ns (part requires 20 ns or
> > greater).
> > 8 = TRP is 1000 = 90 ns (part requires 20 ns or
> > greater).
> > F= TRC is 1111 = 160 ns (part requires 70 ns or
> > greater).
> > 000 = reserved
> >
> > SDTIM 0x 0003 B040 h
> > 00 = reserved
> > 03B = counter value (always changing)
> > 040 = refresh period = 640 ns (part requires
> 15.625
> > u sec or less)
> >
> > CECTL0 0x FFFF 3F33 h
> > xxxx xx3x = M-Type is 32 bit SDRAM. Everything
> else
> > is "don't care"
> >
> > O.K., everything looks fine to me at this point.
> >
> > 4.) Using the XDS510 and CCS (with no GEL file) we
> > can 'peek and poke'
> > into SDRAM. The memory seems fully functional and
> > stable.
> >
> > 5.) Disconnect the emulator via CCS, power down
> the
> > system and enable the
> > flash ram.
> >
> > 6.) Power up the system, reset the DSP using the
> > push button, connect with
> > CCS via the XDS510.
> >
> > 7.) Verify that the EMIF configuration is correct.
> > It is the same as
> > above.
> >
> > 8.) Inspecting the contents of the SDRAM, we can
> see
> > an immediate problem.
> >
> >
> > The secondary bootloader code has not been
> correctly
> > copied into the
> > SDRAM. Many instructions are just fine, but some
> > instructions appear to
> > have gotten a few bits flipped. This, of course,
> is
> > a very bad thing that
> > has lead the secondary boot loader to crash.
> >
> > 9.) Using CCS and the XDS510, issue an EJTAG
> reset.
>
> >>mike>>Please forgive my ignorance - What is an
> "EJTAG reset"?? I am not accustomed to seeing
> 'EJTAG'
> in relation to TI. === message truncated ===
