RAMsandwich

Started by jay_n_vt May 30, 2005
I may be the only one still using the BX01.. but I have board that has
two serial ports, and 32 I/O's (using 74hc589's based on Edwin Cini's
design) with CD74HC4050's as I/O shifter/buffers using the SPI
interface. I also included a 40 pin socket to be able to use the
RAMsandwich from BASICX. Reading the forum.. I found that v2.1 of the
compiler doesn't set BIT 3 high.. (msg 15175). Pins 16,17, 21-28,
32-39 have nothing on them but the header. Same for Pin 2 and 3. The
PDIP description in the BX-01 Ref manual says 2 is Ex RAM A16 and pin
3 is Analog Input.. I've coded both ways to force 2 and or 3 high then
tried to copy data into and out of XRAM. The BX-01 in-circuit emulator
works fine with the RAMsandwich and the code.. on my board, it
doesn't. I saw on the schematic for the Development Station that they
also puled up Pin 31 (PWM) and Pin 28 (A15). tried that also.. no
luck. Has anyone been sucessful using the RAMsandwich on a NON-BASICX
board? Or have any tips on what I'm missing??

Thanks.. Jay


Jay, you are not the only one using the BX01. I use several hundred
a year in a product we manufacture. Although I chose the BX01 for
the option of being able to have lots of external RAM butI haven't
needed it until now.

Anyway, I just did a new board layout incorporating the RAM sandwich
layout with XI/O and I haven't been able to get it to work at all. I
am going to start troubleshooting the board today and will post any
information that I come up with.

Vic Gates

................................................................

--- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> I may be the only one still using the BX01.. but I have board that
has
> two serial ports, and 32 I/O's (using 74hc589's based on Edwin
Cini's
> design) with CD74HC4050's as I/O shifter/buffers using the SPI
> interface. I also included a 40 pin socket to be able to use the
> RAMsandwich from BASICX. Reading the forum.. I found that v2.1 of
the
> compiler doesn't set BIT 3 high.. (msg 15175). Pins 16,17, 21-28,
> 32-39 have nothing on them but the header. Same for Pin 2 and 3.
The
> PDIP description in the BX-01 Ref manual says 2 is Ex RAM A16 and
pin
> 3 is Analog Input..
>
> Thanks.. Jay




BAD BX-01! Don't know why.. I can flip all the bits with a putpin, but
not when accessing the pins as address and data with PUTXRAM! Swapped
in a different BX01 and it works! In the moring I will put the 'bad'
BX back into my "in-Circuit Emulator" and see how it acts..

Jay --- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> I may be the only one still using the BX01.. but I have board that
has
> two serial ports, and 32 I/O's (using 74hc589's based on Edwin
Cini's
> design) with CD74HC4050's as I/O shifter/buffers using the SPI
> interface. I also included a 40 pin socket to be able to use the
> RAMsandwich from BASICX. Reading the forum.. I found that v2.1 of
the
> compiler doesn't set BIT 3 high.. (msg 15175). Pins 16,17, 21-28,
> 32-39 have nothing on them but the header. Same for Pin 2 and 3. The
> PDIP description in the BX-01 Ref manual says 2 is Ex RAM A16 and
pin
> 3 is Analog Input.. I've coded both ways to force 2 and or 3 high
then
> tried to copy data into and out of XRAM. The BX-01 in-circuit
emulator
> works fine with the RAMsandwich and the code.. on my board, it
> doesn't. I saw on the schematic for the Development Station that
they
> also puled up Pin 31 (PWM) and Pin 28 (A15). tried that also.. no
> luck. Has anyone been sucessful using the RAMsandwich on a
NON-BASICX
> board? Or have any tips on what I'm missing??
>
> Thanks.. Jay


In the column, "tuck away in case you ever need this", I was using a
BASICX In-Circuit Emulator to burn my program into the SPI flash. Then
I would move the FLASH to my board. It appears the I/O Pins at startup
are saved in the CPU internal flash! I didn't swap processors, only
the Flash. So the power up / reset state are undetermined! I think if
you use a seperate system to flash the 256k flash, you might want to
swap that processor into the target system along with the flash!

Jay

p.s. which is what must have been what happend in my prior note - the
processor was never really bad, just the init values weren't set
correctly!

--- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> BAD BX-01! Don't know why.. I can flip all the bits with a putpin, but
> not when accessing the pins as address and data with PUTXRAM! Swapped
> in a different BX01 and it works! In the moring I will put the 'bad'
> BX back into my "in-Circuit Emulator" and see how it acts..
>
> Jay > --- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> > I may be the only one still using the BX01.. but I have board that
> has
> > two serial ports, and 32 I/O's (using 74hc589's based on Edwin
> Cini's
> > design) with CD74HC4050's as I/O shifter/buffers using the SPI
> > interface. I also included a 40 pin socket to be able to use the
> > RAMsandwich from BASICX. Reading the forum.. I found that v2.1 of
> the
> > compiler doesn't set BIT 3 high.. (msg 15175). Pins 16,17, 21-28,
> > 32-39 have nothing on them but the header. Same for Pin 2 and 3. The
> > PDIP description in the BX-01 Ref manual says 2 is Ex RAM A16 and
> pin
> > 3 is Analog Input.. I've coded both ways to force 2 and or 3 high
> then
> > tried to copy data into and out of XRAM. The BX-01 in-circuit
> emulator
> > works fine with the RAMsandwich and the code.. on my board, it
> > doesn't. I saw on the schematic for the Development Station that
> they
> > also puled up Pin 31 (PWM) and Pin 28 (A15). tried that also.. no
> > luck. Has anyone been sucessful using the RAMsandwich on a
> NON-BASICX
> > board? Or have any tips on what I'm missing??
> >
> > Thanks.. Jay


jay_n_vt wrote:

> In the column, "tuck away in case you ever need this", I was using a
> BASICX In-Circuit Emulator to burn my program into the SPI flash. Then
> I would move the FLASH to my board. It appears the I/O Pins at startup
> are saved in the CPU internal flash! I didn't swap processors, only
> the Flash. So the power up / reset state are undetermined! I think if
> you use a seperate system to flash the 256k flash, you might want to
> swap that processor into the target system along with the flash!
>
> Jay
>
This has been discussed before. My articles on the internals of BasicX
describe the format of these saved I/O registers in the first 11 bytes
of the system EEPROM (see http://tinyurl.com/7jdl8).

However the recommended best practice is NOT to rely on the Chip dialog
as you have found. Instead you should initialize the pins at the
beginning of your program using PutPin or by writing directly to the
Atmel ports registers using Register.DDRA = &H00 for example. This
avoids the problem you have seen and makes sure that the program does
not have to rely on the correct setup in the BasicX editor Chip dialog.
There are numerous references to this best practice - here is the last
one: http://groups.yahoo.com/group/basicx/message/18558

Mike
http://home.austin.rr.com/perks/basicx/Articles/


--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> jay_n_vt wrote:
>
> > In the column, "tuck away in case you ever need this", I was using a
> > BASICX In-Circuit Emulator to burn my program into the SPI flash. Then
> > I would move the FLASH to my board. It appears the I/O Pins at startup
> > are saved in the CPU internal flash! I didn't swap processors, only
> > the Flash. So the power up / reset state are undetermined! I think if
> > you use a seperate system to flash the 256k flash, you might want to
> > swap that processor into the target system along with the flash!
> >
> > Jay
> >
> This has been discussed before. My articles on the internals of BasicX
> describe the format of these saved I/O registers in the first 11 bytes
> of the system EEPROM (see http://tinyurl.com/7jdl8).
>
> However the recommended best practice is NOT to rely on the Chip dialog
> as you have found. Instead you should initialize the pins at the
> beginning of your program using PutPin or by writing directly to the
> Atmel ports registers using Register.DDRA = &H00 for example. This
> avoids the problem you have seen and makes sure that the program does
> not have to rely on the correct setup in the BasicX editor Chip dialog.
> There are numerous references to this best practice - here is the last
> one: http://groups.yahoo.com/group/basicx/message/18558
>
> Mike
> http://home.austin.rr.com/perks/basicx/Articles/

Thanks for the pointers .. they will help. Jay


Thanks for all the time and thought you put into those articles, they
are well worth bookmarking and giving a good going over.

I agree with you about not relying on the IDE, initializing the Pins
in your program is the safe way to go. There still could be a problem.
.. It appears (to my DVM) that the processor's power up and reset
state is determined by bits set in the processor's internal flash! If
you sharing the SPI bus with the serial flash, the MISO might have
data on it from two sources preventing the serial flash (application
code) from being read and setting those I/O's. The problem seemed to
come with using a processor in one system that has say a cs for a SPI
device as pin 4. In a previous life, that pin might have been
initialized (in a programming environment) as low.
If you burn a new serial flash, and move just that flash to the system
with the SPI device, pin 4 will continue to be set low until the
serial flash is read, which it couldn't be as pin 4 selected the other
SPI device to dump data on MISO. Is it your understanding that the
processor flash has the power up states of the pins in it. And when
the processor is moved to a new system, those states persists? If so,
you have to insure the processor you use has those initial states
programmed in. This might all be in the processor spec. I guess I'll
go read it.. Thanks again for sharing all you have learned!

Jay

--- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> --- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> > jay_n_vt wrote:
> >
> > > In the column, "tuck away in case you ever need this", I was
using a
> > > BASICX In-Circuit Emulator to burn my program into the SPI
flash. Then
> > > I would move the FLASH to my board. It appears the I/O Pins at
startup
> > > are saved in the CPU internal flash! I didn't swap processors,
only
> > > the Flash. So the power up / reset state are undetermined! I
think if
> > > you use a seperate system to flash the 256k flash, you might
want to
> > > swap that processor into the target system along with the flash!
> > >
> > > Jay
> > >
> > This has been discussed before. My articles on the internals of
BasicX
> > describe the format of these saved I/O registers in the first 11
bytes
> > of the system EEPROM (see http://tinyurl.com/7jdl8).
> >
> > However the recommended best practice is NOT to rely on the Chip
dialog
> > as you have found. Instead you should initialize the pins at the
> > beginning of your program using PutPin or by writing directly to
the
> > Atmel ports registers using Register.DDRA = &H00 for example.
This
> > avoids the problem you have seen and makes sure that the program
does
> > not have to rely on the correct setup in the BasicX editor Chip
dialog.
> > There are numerous references to this best practice - here is the
last
> > one: http://groups.yahoo.com/group/basicx/message/18558
> >
> > Mike
> > http://home.austin.rr.com/perks/basicx/Articles/
>
> Thanks for the pointers .. they will help. Jay



Jay,

It appears to me that the AVR powers up with random states for its
ports. So in my view you should definitely use external pullup or
pulldown resistors where needed to stop unwanted effects like enabling a
motor on reset.

Early on in the power up sequence the main BasicX runtime gets control
and one of the things it does it copy the first 11 AVR EEPROM bytes to
the corresponding port registers. Then some time after that the first
instruction is loaded from the SPI EEPROM and executed. To be safe you
can set the ports to all be inputs on the chip dialog (the default) and
then explicitly set them in your code. When you say processor flash I
think you mean processor EEPROM because the processor flash cannot be
changed by BasicX.

I don't think your DVM is necessarily fast enough to catch all the state
changes of pins. You might need a digital scope or logic analyzer for that.

Don, do I have this right?

> Thanks for all the time and thought you put into those articles, they
> are well worth bookmarking and giving a good going over.
>
> I agree with you about not relying on the IDE, initializing the Pins
> in your program is the safe way to go. There still could be a problem.
> .. It appears (to my DVM) that the processor's power up and reset
> state is determined by bits set in the processor's internal flash! If
> you sharing the SPI bus with the serial flash, the MISO might have
> data on it from two sources preventing the serial flash (application
> code) from being read and setting those I/O's. The problem seemed to
> come with using a processor in one system that has say a cs for a SPI
> device as pin 4. In a previous life, that pin might have been
> initialized (in a programming environment) as low.
> If you burn a new serial flash, and move just that flash to the system
> with the SPI device, pin 4 will continue to be set low until the
> serial flash is read, which it couldn't be as pin 4 selected the other
> SPI device to dump data on MISO. Is it your understanding that the
> processor flash has the power up states of the pins in it. And when
> the processor is moved to a new system, those states persists? If so,
> you have to insure the processor you use has those initial states
> programmed in. This might all be in the processor spec. I guess I'll
> go read it.. Thanks again for sharing all you have learned!
>
> Jay >
>
> --- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> > --- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> > > jay_n_vt wrote:
> > >
> > > > In the column, "tuck away in case you ever need this", I was
> using a
> > > > BASICX In-Circuit Emulator to burn my program into the SPI
> flash. Then
> > > > I would move the FLASH to my board. It appears the I/O Pins at
> startup
> > > > are saved in the CPU internal flash! I didn't swap processors,
> only
> > > > the Flash. So the power up / reset state are undetermined! I
> think if
> > > > you use a seperate system to flash the 256k flash, you might
> want to
> > > > swap that processor into the target system along with the flash!
> > > >
> > > > Jay
> > > >
> > > This has been discussed before. My articles on the internals of
> BasicX
> > > describe the format of these saved I/O registers in the first 11
> bytes
> > > of the system EEPROM (see http://tinyurl.com/7jdl8).
> <http://tinyurl.com/7jdl8%29.>
> > >
> > > However the recommended best practice is NOT to rely on the Chip
> dialog
> > > as you have found. Instead you should initialize the pins at the
> > > beginning of your program using PutPin or by writing directly to
> the
> > > Atmel ports registers using Register.DDRA = &H00 for example.
> This
> > > avoids the problem you have seen and makes sure that the program
> does
> > > not have to rely on the correct setup in the BasicX editor Chip
> dialog.
> > > There are numerous references to this best practice - here is the
> last
> > > one: http://groups.yahoo.com/group/basicx/message/18558
> > >
> > > Mike
> > > http://home.austin.rr.com/perks/basicx/Articles/
> >
> > Thanks for the pointers .. they will help. Jay


--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> It appears to me that the AVR powers up with random states
> for its ports.

According to the AVR documentation all PORTx and DDRx registers are
cleared when the device is reset (including power-on reset). This
means that all I/O pins will be configured as inputs with the pullup
disabled.

After the interpreter begins running it probably configures the I/O
pins using data stored in EEPROM. This data is believed to originate
from the Chip Dialog in the IDE.

Don


Hi!

It's nice to see that my designs are being used by other people :)
I hope you guys found them useful as a starting point.

About the problem of the processor failing to boot when sharing the
SPI bus, I remember having the same problem in the past. The
solution was to use a CD4066 quad analogue switch. Connect the
enable signals together, and then to the CS of the external 25C256
flash. Route each CS signal for your external SPI devices through
an analogue switch. Put a pullup resistor on the output of the
switch, and you have guaranteed booting each time. No matter what
the inital state of the individual CS pins is, because as soon as
the processor tries to access the external flash, the other devices
are automatically disabled.

Hope it helps!

Cheers,

Edwin

--- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> Thanks for all the time and thought you put into those articles,
they
> are well worth bookmarking and giving a good going over.
>
> I agree with you about not relying on the IDE, initializing the
Pins
> in your program is the safe way to go. There still could be a
problem.
> .. It appears (to my DVM) that the processor's power up and reset
> state is determined by bits set in the processor's internal flash!
If
> you sharing the SPI bus with the serial flash, the MISO might have
> data on it from two sources preventing the serial flash
(application
> code) from being read and setting those I/O's. The problem seemed
to
> come with using a processor in one system that has say a cs for a
SPI
> device as pin 4. In a previous life, that pin might have been
> initialized (in a programming environment) as low.
> If you burn a new serial flash, and move just that flash to the
system
> with the SPI device, pin 4 will continue to be set low until the
> serial flash is read, which it couldn't be as pin 4 selected the
other
> SPI device to dump data on MISO. Is it your understanding that the
> processor flash has the power up states of the pins in it. And when
> the processor is moved to a new system, those states persists? If
so,
> you have to insure the processor you use has those initial states
> programmed in. This might all be in the processor spec. I guess
I'll
> go read it.. Thanks again for sharing all you have learned!
>
> Jay >
>
> --- In basicx@basi..., "jay_n_vt" <jay_n_vt@y...> wrote:
> > --- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> > > jay_n_vt wrote:
> > >
> > > > In the column, "tuck away in case you ever need this", I was
> using a
> > > > BASICX In-Circuit Emulator to burn my program into the SPI
> flash. Then
> > > > I would move the FLASH to my board. It appears the I/O Pins
at
> startup
> > > > are saved in the CPU internal flash! I didn't swap
processors,
> only
> > > > the Flash. So the power up / reset state are undetermined! I
> think if
> > > > you use a seperate system to flash the 256k flash, you might
> want to
> > > > swap that processor into the target system along with the
flash!
> > > >
> > > > Jay
> > > >
> > > This has been discussed before. My articles on the internals of
> BasicX
> > > describe the format of these saved I/O registers in the first
11
> bytes
> > > of the system EEPROM (see http://tinyurl.com/7jdl8).
> > >
> > > However the recommended best practice is NOT to rely on the
Chip
> dialog
> > > as you have found. Instead you should initialize the pins at
the
> > > beginning of your program using PutPin or by writing directly
to
> the
> > > Atmel ports registers using Register.DDRA = &H00 for example.
> This
> > > avoids the problem you have seen and makes sure that the
program
> does
> > > not have to rely on the correct setup in the BasicX editor Chip
> dialog.
> > > There are numerous references to this best practice - here is
the
> last
> > > one: http://groups.yahoo.com/group/basicx/message/18558
> > >
> > > Mike
> > > http://home.austin.rr.com/perks/basicx/Articles/
> >
> > Thanks for the pointers .. they will help. Jay