linuxsh-dev

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[Doug M. <mar...@sy...>]

First a couple of questions;
    1. What is the state of /RDY?
    2. What is the state of /MRESET?
    3. What is the state of /TRST?
    4. During power up reset and operation what was the mode pin settings, =
and was the correct timing observed?
    5. What type of memory and in what configuration is the memory =
configured?

Getting the board to read the reset vector is the first hurdle.  The =
second hurdle with the SH4 is the proper start timing configuration for =
DRAM/SDRAM!

Doug Martens
Senior Design Engineer
mar...@sy...
1000 Waverley St.
Winnipeg, MB, Canada
R3T 0P3
Symbol Technologies, Winnipeg
Ph: (204) 478-8046
www.symbol.com


>>> Barkuson <bar...@ya...> 07/04/01 08:42AM >>>

Hi,

Firstly, my apologies for sending this mail if this is
not relevent to the mailing list. However, this is
quite urgent, sorry. Could any hardware people help me
out please?

I have a custom Sh4 (SH7750) board which has not been
able to run :(. Everything looks alright except that
the board boots up and sits at address 0x00000000 (the
data at this address in the flash memory is on the
data bus). The CPU seems to halt at this point with
the following board status,

- both main crystal and rtc crystal running
- both status pin at low level
- all NMI and IRL pins pulled up
- BREQ pulled up
- address sits at 0x00000000 and does not increments
- CS0 low=20
- RD low
- all WE high

Is there anything else that I should check?? or any
setting that I could be missing??

Can anyone direct me to a right place??

All helps are greatly appreciated.=20

Mark


___________________________________________________________________________=
__
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[<bar...@ya...>]

Hi Doug:

Thanks for your help, you are a life saver.
I went through the following pins and tried different
settings. Unfortunately, the address line still does
not advance from reset address 0x00000000.

>First a couple of questions;
>    1. What is the state of /RDY?
This pin is pulled high, and sits on high.

>    2. What is the state of /MRESET?
This pin is also pulled high and sits on high.

>    3. What is the state of /TRST?
This pin is pulled low. If this pin is pulled high,
the CPU stays in reset status.

>    4. During power up reset and operation what was
>the mode pin settings, and was the correct timing
>observed?
The mod pins are as followed:
MOD0 high
MOD1 low
MOD2 high   (for 6:3:3/2 clock setting)

MOD3 high
MOD4 low    (8 bit for Area 0 - 8 bit Flash memory)

MOD5 high   little endian
MOD6 high   normal memory
MOD7 high   master
MOD8 high   crystal resonator

Orignally, the 1.95 is brought up around 200ms after
3.3V, the reset line becomes high at the same time as
the 1.95V.
The reset circuit was modified, now, the reset line
comes up 150ms after 1.95V is up. 

>    5. What type of memory and in what configuration
>is the memory configured?
Area 0 1MB FLASH memory 10MHz (8bit data bus)
Area 3 8MB SDRAM 100MHz  (32bit data bus)
Area 4 512kB SRAM 100MHz (32bit data bus)
 
>Getting the board to read the reset vector is the
>first hurdle.  The second hurdle with the SH4 is the
>proper start timing configuration for DRAM/SDRAM!

Is there anything else I should look out for??? I
suppose that this can only be a hardware problem (pin
settings). Since that bus should read at least 2 8-bit
data from the Flash memory before the first
instruction is fetched for execution. Is this true??

Thanks again, 

Mark



 --- Doug Martens <mar...@sy...> wrote: > First
a couple of questions;
>     1. What is the state of /RDY?
>     2. What is the state of /MRESET?
>     3. What is the state of /TRST?
>     4. During power up reset and operation what was
> the mode pin settings, and was the correct timing
> observed?
>     5. What type of memory and in what configuration
> is the memory configured?
> 
> Getting the board to read the reset vector is the
> first hurdle.  The second hurdle with the SH4 is the
> proper start timing configuration for DRAM/SDRAM!
> 
> Doug Martens
> Senior Design Engineer
> mar...@sy...
> 1000 Waverley St.
> Winnipeg, MB, Canada
> R3T 0P3
> Symbol Technologies, Winnipeg
> Ph: (204) 478-8046
> www.symbol.com
> 
> 
> >>> Barkuson <bar...@ya...> 07/04/01 08:42AM
> >>>
> 
> Hi,
> 
> Firstly, my apologies for sending this mail if this
> is
> not relevent to the mailing list. However, this is
> quite urgent, sorry. Could any hardware people help
> me
> out please?
> 
> I have a custom Sh4 (SH7750) board which has not
> been
> able to run :(. Everything looks alright except that
> the board boots up and sits at address 0x00000000
> (the
> data at this address in the flash memory is on the
> data bus). The CPU seems to halt at this point with
> the following board status,
> 
> - both main crystal and rtc crystal running
> - both status pin at low level
> - all NMI and IRL pins pulled up
> - BREQ pulled up
> - address sits at 0x00000000 and does not increments
> - CS0 low 
> - RD low
> - all WE high
> 
> Is there anything else that I should check?? or any
> setting that I could be missing??
> 
> Can anyone direct me to a right place??
> 
> All helps are greatly appreciated. 
> 
> Mark
> 
> 
>
_____________________________________________________________________________
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
>  

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[Doug M. <mar...@sy...>]

Barkuson,

The /RDY line should be idled low and actively driven high when the user =
wishes to add extra wait states beyond what is required through the bus =
state controller(BSC).  The BSC acts differently then expected.  First it =
waits the required number of cycles programmed within the BSC in WCR2(wait =
control register 2) then it samples /RDY waiting for that line to be =
asserted.  After that line is asserted it will end that cycle successfully.=
  The default mode, which is what you will observe at reset time, is 15 =
cycles inserted and then wait for /RDY assertion.

Change your hardware to idle /RDY low during at least CS0 accesses.  =
Hopefully this helps.

Doug Martens
Senior Design Engineer
mar...@sy...
1000 Waverley St.
Winnipeg, MB, Canada
R3T 0P3
Symbol Technologies, Winnipeg
Ph: (204) 478-8046
www.symbol.com


>>> Barkuson <bar...@ya...> 07/04/01 12:58PM >>>
Hi Doug:

Thanks for your help, you are a life saver.
I went through the following pins and tried different
settings. Unfortunately, the address line still does
not advance from reset address 0x00000000.

>First a couple of questions;
>    1. What is the state of /RDY?
This pin is pulled high, and sits on high.

>    2. What is the state of /MRESET?
This pin is also pulled high and sits on high.

>    3. What is the state of /TRST?
This pin is pulled low. If this pin is pulled high,
the CPU stays in reset status.

>    4. During power up reset and operation what was
>the mode pin settings, and was the correct timing
>observed?
The mod pins are as followed:
MOD0 high
MOD1 low
MOD2 high   (for 6:3:3/2 clock setting)

MOD3 high
MOD4 low    (8 bit for Area 0 - 8 bit Flash memory)

MOD5 high   little endian
MOD6 high   normal memory
MOD7 high   master
MOD8 high   crystal resonator

Orignally, the 1.95 is brought up around 200ms after
3.3V, the reset line becomes high at the same time as
the 1.95V.
The reset circuit was modified, now, the reset line
comes up 150ms after 1.95V is up.=20

>    5. What type of memory and in what configuration
>is the memory configured?
Area 0 1MB FLASH memory 10MHz (8bit data bus)
Area 3 8MB SDRAM 100MHz  (32bit data bus)
Area 4 512kB SRAM 100MHz (32bit data bus)

>Getting the board to read the reset vector is the
>first hurdle.  The second hurdle with the SH4 is the
>proper start timing configuration for DRAM/SDRAM!

Is there anything else I should look out for??? I
suppose that this can only be a hardware problem (pin
settings). Since that bus should read at least 2 8-bit
data from the Flash memory before the first
instruction is fetched for execution. Is this true??

Thanks again,=20

Mark



--- Doug Martens <mar...@sy...> wrote: > First
a couple of questions;
>     1. What is the state of /RDY?
>     2. What is the state of /MRESET?
>     3. What is the state of /TRST?
>     4. During power up reset and operation what was
> the mode pin settings, and was the correct timing
> observed?
>     5. What type of memory and in what configuration
> is the memory configured?
>=20
> Getting the board to read the reset vector is the
> first hurdle.  The second hurdle with the SH4 is the
> proper start timing configuration for DRAM/SDRAM!
>=20
> Doug Martens
> Senior Design Engineer
> mar...@sy...
> 1000 Waverley St.
> Winnipeg, MB, Canada
> R3T 0P3
> Symbol Technologies, Winnipeg
> Ph: (204) 478-8046
> www.symbol.com
>=20
>=20
> >>> Barkuson <bar...@ya...> 07/04/01 08:42AM
> >>>
>=20
> Hi,
>=20
> Firstly, my apologies for sending this mail if this
> is
> not relevent to the mailing list. However, this is
> quite urgent, sorry. Could any hardware people help
> me
> out please?
>=20
> I have a custom Sh4 (SH7750) board which has not
> been
> able to run :(. Everything looks alright except that
> the board boots up and sits at address 0x00000000
> (the
> data at this address in the flash memory is on the
> data bus). The CPU seems to halt at this point with
> the following board status,
>=20
> - both main crystal and rtc crystal running
> - both status pin at low level
> - all NMI and IRL pins pulled up
> - BREQ pulled up
> - address sits at 0x00000000 and does not increments
> - CS0 low=20
> - RD low
> - all WE high
>=20
> Is there anything else that I should check?? or any
> setting that I could be missing??
>=20
> Can anyone direct me to a right place??
>=20
> All helps are greatly appreciated.=20
>=20
> Mark
>=20
>=20
>
___________________________________________________________________________=
__
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
> =20

___________________________________________________________________________=
__
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[<bar...@ya...>]

Thanks, Doug.

/RDY was pulled up by an FPGA pin. After adding a
pulled down resister, the cpu now reads from the Flash
and executing the sh-ipl now (well not quite, still
need to set up the SDRAM). Thanks again.

Mark


 --- Doug Martens <mar...@sy...> wrote: >
Barkuson,
> 
> The /RDY line should be idled low and actively
> driven high when the user wishes to add extra wait
> states beyond what is required through the bus state
> controller(BSC).  The BSC acts differently then
> expected.  First it waits the required number of
> cycles programmed within the BSC in WCR2(wait
> control register 2) then it samples /RDY waiting for
> that line to be asserted.  After that line is
> asserted it will end that cycle successfully.  The
> default mode, which is what you will observe at
> reset time, is 15 cycles inserted and then wait for
> /RDY assertion.
> 
> Change your hardware to idle /RDY low during at
> least CS0 accesses.  Hopefully this helps.
> 
> Doug Martens
> Senior Design Engineer
> mar...@sy...
> 1000 Waverley St.
> Winnipeg, MB, Canada
> R3T 0P3
> Symbol Technologies, Winnipeg
> Ph: (204) 478-8046
> www.symbol.com
> 
> 
> >>> Barkuson <bar...@ya...> 07/04/01 12:58PM
> >>>
> Hi Doug:
> 
> Thanks for your help, you are a life saver.
> I went through the following pins and tried
> different
> settings. Unfortunately, the address line still does
> not advance from reset address 0x00000000.
> 
> >First a couple of questions;
> >    1. What is the state of /RDY?
> This pin is pulled high, and sits on high.
> 
> >    2. What is the state of /MRESET?
> This pin is also pulled high and sits on high.
> 
> >    3. What is the state of /TRST?
> This pin is pulled low. If this pin is pulled high,
> the CPU stays in reset status.
> 
> >    4. During power up reset and operation what was
> >the mode pin settings, and was the correct timing
> >observed?
> The mod pins are as followed:
> MOD0 high
> MOD1 low
> MOD2 high   (for 6:3:3/2 clock setting)
> 
> MOD3 high
> MOD4 low    (8 bit for Area 0 - 8 bit Flash memory)
> 
> MOD5 high   little endian
> MOD6 high   normal memory
> MOD7 high   master
> MOD8 high   crystal resonator
> 
> Orignally, the 1.95 is brought up around 200ms after
> 3.3V, the reset line becomes high at the same time
> as
> the 1.95V.
> The reset circuit was modified, now, the reset line
> comes up 150ms after 1.95V is up. 
> 
> >    5. What type of memory and in what
> configuration
> >is the memory configured?
> Area 0 1MB FLASH memory 10MHz (8bit data bus)
> Area 3 8MB SDRAM 100MHz  (32bit data bus)
> Area 4 512kB SRAM 100MHz (32bit data bus)
> 
> >Getting the board to read the reset vector is the
> >first hurdle.  The second hurdle with the SH4 is
> the
> >proper start timing configuration for DRAM/SDRAM!
> 
> Is there anything else I should look out for??? I
> suppose that this can only be a hardware problem
> (pin
> settings). Since that bus should read at least 2
> 8-bit
> data from the Flash memory before the first
> instruction is fetched for execution. Is this true??
> 
> Thanks again, 
> 
> Mark
> 
> 
> 
> --- Doug Martens <mar...@sy...> wrote: >
> First
> a couple of questions;
> >     1. What is the state of /RDY?
> >     2. What is the state of /MRESET?
> >     3. What is the state of /TRST?
> >     4. During power up reset and operation what
> was
> > the mode pin settings, and was the correct timing
> > observed?
> >     5. What type of memory and in what
> configuration
> > is the memory configured?
> > 
> > Getting the board to read the reset vector is the
> > first hurdle.  The second hurdle with the SH4 is
> the
> > proper start timing configuration for DRAM/SDRAM!
> > 
> > Doug Martens
> > Senior Design Engineer
> > mar...@sy...
> > 1000 Waverley St.
> > Winnipeg, MB, Canada
> > R3T 0P3
> > Symbol Technologies, Winnipeg
> > Ph: (204) 478-8046
> > www.symbol.com
> > 
> > 
> > >>> Barkuson <bar...@ya...> 07/04/01 08:42AM
> > >>>
> > 
> > Hi,
> > 
> > Firstly, my apologies for sending this mail if
> this
> > is
> > not relevent to the mailing list. However, this is
> > quite urgent, sorry. Could any hardware people
> help
> > me
> > out please?
> > 
> > I have a custom Sh4 (SH7750) board which has not
> > been
> > able to run :(. Everything looks alright except
> that
> > the board boots up and sits at address 0x00000000
> > (the
> > data at this address in the flash memory is on the
> > data bus). The CPU seems to halt at this point
> with
> > the following board status,
> > 
> > - both main crystal and rtc crystal running
> > - both status pin at low level
> > - all NMI and IRL pins pulled up
> > - BREQ pulled up
> > - address sits at 0x00000000 and does not
> increments
> > - CS0 low 
> > - RD low
> > - all WE high
> > 
> > Is there anything else that I should check?? or
> any
> > setting that I could be missing??
> > 
> > Can anyone direct me to a right place??
> > 
> > All helps are greatly appreciated. 
> > 
> > Mark
> > 
> > 
> >
>
_____________________________________________________________________________
> > http://messenger.yahoo.com.au - Yahoo! Messenger
> > - Voice chat, mail alerts, stock quotes and
> > favourite news and lots more!
> >  
> 
>
_____________________________________________________________________________
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
>  

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: [linux-sh:01769] Re: SH4 hardware problem

[Gareth S. L. <ga...@el...>]

In message <200...@we...>
          Barkuson <bar...@ya...> wrote:

> Thanks, Doug.
> 
> /RDY was pulled up by an FPGA pin. After adding a
> pulled down resister, the cpu now reads from the Flash
> and executing the sh-ipl now (well not quite, still
> need to set up the SDRAM). Thanks again.

A little tip that I found useful - if you modify the CCR initialisation to
use part of the cache as memory mapped RAM, you can use this area for the
IPL's stack and variable storage - then you can use the debugger to test the
presence of the SDRAM in area 2 or 3 without having to reflash all the time.

-- 
Gatch

[linuxsh-dev] Re: [linux-sh:01781] Re: SH4 hardware problem

[<bar...@ya...>]

Gareth:

Thanks for the tips. It provides instant boot up
without worrying about external memories.

However, I went a step further. Since I am not good at
using GDB. I wrote a small procedure in sh-ipl+g and a
PC software that talks on serial line. The combination
loads a binary file (sh executable file mapped on to
part of the cache ram) on to the spare area of the
cache ram. Upon completion of downloading the binary,
sh-ipl+g jumps to the starting address of the download
binary and start executing the file as a procedure.

The downloaded binary has to be small enough to fit
into the cache ram (it is basically just entry.S and
main.c). This binary sets up SDRAM (all neccessary
parameters only) and does SDRAM memory read-write test
within the requested block then it outputs the results
back to PC on serial line. 
Well, this may sound complex, but it is just a work
around for me to avoid using GDB.

Thanks for the tip again.

Mark.


_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!