Serial flash and PB0 on RCM 3700

Hi!

I am new at programming rabbits.
Recently I'm trying to use serial flash on my existing hardware where
I already use serial ports C, D and E. I have seen that some people
had trouble using serial flash with serial ports. I am also using PB0
as input. As this pin is connected to serial flash (SCK) is it still
possible to use serial flash?

Thanks for all the suggestions!

Matjaz Start a New Thread

By now I have tried to use the macros from SFLASH.LIB
#define SF_SERPORT SCDR
#define SF_SERPORT SADR
that assign different serial channels to work with serial flash. When
using serial A you have to disconnect programming cable and therefore
loose debugging option.
Nevertheless those macros don't affect the PB0 problem. When I assign
PB0 to be an output after sfspi_init() the use of serial flash is
impossible.
On RCM3700 Schematic at
http://www.rabbitsemiconductor.com/documentation/schemat/090-0177.pdf
it is shown that PB0 is directly connected to the serial flash SCK
pin, although this pin is also on 40 pin header.
The use of this pin is obviously alternate...
It seems we will have to redesign the PCB.

Any comments still welcome.

Matjaz





Start a New Thread

Matjaz,
I dont have direct experience with the RCM3700, but I have used sflash.lib
successfully with a SF1000 board on a RCM3400. It does work.

Following is the setup I use for my system:
****************************************************************************
********
// Set up #defines to use SF1000 with sflash.lib
// sflash.lib uses serial port D
#define SF_SERPORT SDDR

// Special SPI setup for SF1000
#define SF_SPI_DIVISOR 5 // 5 recommended in a manual somewhere, lower
(faster) may also work.
#define SF_SPI_INVERT_RX

// tell sflash.lib to use PD6 for SF1000 chip select
#define SF_SPI_CSPORT PDDR // data register for port with CS pin (e.g.
PEDR)
#define SF_SPI_CSSHADOW PDDRShadow // shadow varible for data register (e.g.
PEDRShadow)
#define SF_SPI_CSDD PDDDR // data direction register for CS pin (e.g.
PEDDR)
#define SF_SPI_CSDDSHADOW PDDDRShadow // shadow for data direction register
(PEDDRShadow)
#define SF_SPI_CSPIN 6 // pin number of CS (e.g. 6)

#use sflash.lib

... Snip...

// Initialize the SF1000 card
sf_init();
sf_initDevice( &SFdev, SF_SPI_CSPORT, &SF_SPI_CSSHADOW,SF_SPI_CSPIN );

****************************************************************************
********

>From what I can see on the RCM3700 schematic you need to define the serial
port as SBDR and the chip select as PE6.

Don't define PB0 as an output - you want it to have its 'alternate'
function, CLKB. You shouldnt need to manually configure any of the pins;
the calls to sf_init() and sf_initDevice() take care of everything.

NB: I recall that some of the documentation was incorrect - it suggested
calling sfspi_init() or something like that instead of sf_init() - but the
example code was right. What I have shown above works.

Since the serial flash is integrated into the RCM3700, you should find some
examples in the sample code that are set up exactly right. Try them.

Oh, and incidentally, watch out for the race condition bug with the CS
enable and disable functions in sflash.lib - search the archives for my post
about this earlier.

Will

> -----Original Message-----
> From: r...
> [mailto:r...] On Behalf Of matjazkariz
> Sent: Wednesday, May 10, 2006 08:09
> To: r...
> Subject: [rabbit-semi] Re: Serial flash and PB0 on RCM 3700
>
> By now I have tried to use the macros from SFLASH.LIB #define
> SF_SERPORT SCDR #define SF_SERPORT SADR that assign different
> serial channels to work with serial flash. When using serial
> A you have to disconnect programming cable and therefore
> loose debugging option.
> Nevertheless those macros don't affect the PB0 problem. When
> I assign PB0 to be an output after sfspi_init() the use of
> serial flash is impossible.
> On RCM3700 Schematic at
> http://www.rabbitsemiconductor.com/documentation/schemat/090-0177.pdf
> it is shown that PB0 is directly connected to the serial
> flash SCK pin, although this pin is also on 40 pin header.
> The use of this pin is obviously alternate...
> It seems we will have to redesign the PCB.
>
> Any comments still welcome.
>
> Matjaz
>
>
>
>
>
>
>
>
>
>
>
>
>
Start a New Thread