Hello Group,

I am using Keil RealView on an LPC2210 target. Recently, I decided to
use 16-bit external memory interface on an S29AL016D flash memory
chip. Usually, the Keil compiler provides flash programming algorithms
to program any flash chip whether internal or external. I checked for
a programming algorithm that will match the memory chip I am using and
it turns out that there is an algorithm AM29F160DT in Keil that
matches the architecture completely with the S29 flash chip I am using.

I am still getting memory content mismatch erorrs. Is there anything
else I have to change besides the PINSEL2 and the EMC BCFG registers?

Has anyone else used a 16-bit interface instead of 32-bit (which is so
common, it seems its almost defaulted).?

Thanks.

Karim. Start a New Thread

wickedmonster2002 wrote:
>
> Hello Group,
>
> I am using Keil RealView on an LPC2210 target. Recently, I decided to
> use 16-bit external memory interface on an S29AL016D flash memory
> chip. Usually, the Keil compiler provides flash programming algorithms
> to program any flash chip whether internal or external. I checked for
> a programming algorithm that will match the memory chip I am using and
> it turns out that there is an algorithm AM29F160DT in Keil that
> matches the architecture completely with the S29 flash chip I am using.
>
> I am still getting memory content mismatch erorrs. Is there anything
> else I have to change besides the PINSEL2 and the EMC BCFG registers?
>
> Has anyone else used a 16-bit interface instead of 32-bit (which is so
> common, it seems its almost defaulted).?
>
I'm not using Keil, just gcc to configure the external memory controller
to use a 16bit bus to a CY7C1041C33 (Cypress) SRAM. All I had to do was
program the bits up for PINSEL2 (value: 0x0d6029d4), BCFG1 (0x1000ffef),
and set XCLKDIV to the same value as VPBDIV. XCLKDIV sets the timing
for the external memory bus clock.

I would suspect that you would do something similar with your values?

I'm just starting to bring the system up now, so I'm using conservative
values for timings (hence the BCFG1 values). I did configure it to:
A1..A19 as address lines (PINSEL2 stuff), RBLE bit set in BCFG1 for "non
8bit byte wide data bus", and MW set to "0x1" for 16bit databus in
BCFG1. My FOSC is 14.7456MHz, PLL MULT is 4, and the PBSD is set for 2,
with the VPBDIV + XCLKDIV set at 3.

One of the advantages of having source code to your libraries is that
you can debug things like this. Does keil give you the source to the
programming lib? I don't recognize the error message you gave so I'm
assuming this is a return value from the keil lib?

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

Tom Walsh wrote:
>
> wickedmonster2002 wrote:
> >
> > Hello Group,
> >
> > I am using Keil RealView on an LPC2210 target. Recently, I decided to
> > use 16-bit external memory interface on an S29AL016D flash memory
> > chip. Usually, the Keil compiler provides flash programming algorithms
> > to program any flash chip whether internal or external. I checked for
> > a programming algorithm that will match the memory chip I am using and
> > it turns out that there is an algorithm AM29F160DT in Keil that
> > matches the architecture completely with the S29 flash chip I am using.
> >
> > I am still getting memory content mismatch erorrs. Is there anything
> > else I have to change besides the PINSEL2 and the EMC BCFG registers?
> >
> > Has anyone else used a 16-bit interface instead of 32-bit (which is so
> > common, it seems its almost defaulted).?
>
OH! Just a thought, if you have a commercial JTAG unit, they have Flash
programming built in. Perhaps you could program the Flash from JTAG,
then configure the processor PINSEL2, XCLKDIV and BCFGx registers, then
look to see if you can verify the data that is in the Flash?

Another thing, I usually move address lines around for RAM (also the
8bit low & high byte) of the device (RAM / Flash) when I lay the board
out. Are your address + data lines as they should be? It could be a
hardware issue..

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

Thanks Tom,

Actually, it wasn't software or compiler. The flash algorithm I used
for this chip turned out to be just right. I am also using a ULINK as
my JTAG, so yes, it did have a flash programming unit built in, but it
used those algortihms to do it.

Apparently, the problem was the boot pins and I believe, pin P014 of
the chip.

I connected a pull down resistor to BOOT1 pin and left BOOT0 pin
floating. The datasheet mentions that if the pins are left
unconnected, internal resistances pull them up to high. So I left that
floating and I shouldn't have done that, internal resistance be damned.

I also had the same situation with SSEL pin for the SPI. I just set to
to GPIO pin and set it high in software. My SPI still did not work.
Struggled with it for 3 days and then, just out of curiosity, I just
pulled up the SSEL pin in hardware, and SPI worked. I don't why the
datasheet sometimes claims to be something but it isn't.

The other thing I changed was I pulled up the P014 pin because the
datasheet mentions that if this pin is low while /RESET is low, the
controller will enter ISP mode. Otherwise, it will remap interrupts to
External memory.

Oh well, it goes on. Ol' Murphy is always out to get me the first
three days of the week.

Thanks again for your input, I learned a bit from them.

Karim.

--- In l..., Tom Walsh wrote:
>
> Tom Walsh wrote:
> >
> > wickedmonster2002 wrote:
> > >
> > > Hello Group,
> > >
> > > I am using Keil RealView on an LPC2210 target. Recently, I
decided to
> > > use 16-bit external memory interface on an S29AL016D flash memory
> > > chip. Usually, the Keil compiler provides flash programming
algorithms
> > > to program any flash chip whether internal or external. I
checked for
> > > a programming algorithm that will match the memory chip I am
using and
> > > it turns out that there is an algorithm AM29F160DT in Keil that
> > > matches the architecture completely with the S29 flash chip I am
using.
> > >
> > > I am still getting memory content mismatch erorrs. Is there anything
> > > else I have to change besides the PINSEL2 and the EMC BCFG
registers?
> > >
> > > Has anyone else used a 16-bit interface instead of 32-bit (which
is so
> > > common, it seems its almost defaulted).?
> >
> OH! Just a thought, if you have a commercial JTAG unit, they have
Flash
> programming built in. Perhaps you could program the Flash from JTAG,
> then configure the processor PINSEL2, XCLKDIV and BCFGx registers, then
> look to see if you can verify the data that is in the Flash?
>
> Another thing, I usually move address lines around for RAM (also the
> 8bit low & high byte) of the device (RAM / Flash) when I lay the board
> out. Are your address + data lines as they should be? It could be a
> hardware issue..
>
> TomW
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net http://cyberiansoftware.com http://openzipit.org
> "Windows? No thanks, I have work to do..."
> ----------------
> Start a New Thread

wickedmonster2002 wrote:
>
> Thanks Tom,
>
> Actually, it wasn't software or compiler. The flash algorithm I used
> for this chip turned out to be just right. I am also using a ULINK as
> my JTAG, so yes, it did have a flash programming unit built in, but it
> used those algortihms to do it.
>
> Apparently, the problem was the boot pins and I believe, pin P014 of
> the chip.
>
> I connected a pull down resistor to BOOT1 pin and left BOOT0 pin
> floating. The datasheet mentions that if the pins are left
> unconnected, internal resistances pull them up to high. So I left that
> floating and I shouldn't have done that, internal resistance be damned.
>
> I also had the same situation with SSEL pin for the SPI. I just set to
> to GPIO pin and set it high in software. My SPI still did not work.
> Struggled with it for 3 days and then, just out of curiosity, I just
> pulled up the SSEL pin in hardware, and SPI worked. I don't why the
> datasheet sometimes claims to be something but it isn't.
>
I've gotten nailed by the floating / GPIO use of the SSEL input myself.
Hey, "you get burned you learn", that is what employers (and customers)
pay you for: experience.

After a few years, you realize that as much as you hate to do
documentation, so it is with others. So, it was some engineer who told
some tech writer what it was that the engineer built. As the tech
writer has a limited amount of intelligence (otherwise they'd be
engineers), they will get something totally wrong in the
documentation... Maybe even several things. heh

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

--- In l..., Tom Walsh wrote:
> As the tech
> writer has a limited amount of intelligence (otherwise they'd be
> engineers), they will get something totally wrong in the
> documentation... Maybe even several things. heh
>

Tom,

Hard as it might be for you to believe, but not everyone wants to be
an engineer!

It's my experience that good tech writers are actually harder to
find than good engineers.

I guess it's a matter of opinion on whether it takes more
intelligence to write clear, lucid and accurate documents than
engineer products that actually work as advertised :-)

Brendan Start a New Thread

--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., Tom Walsh wrote:
> > As the tech
> > writer has a limited amount of intelligence (otherwise they'd be
> > engineers), they will get something totally wrong in the
> > documentation... Maybe even several things. heh
> > Tom,
>
> Hard as it might be for you to believe, but not everyone wants to be
> an engineer!

True.
Some [of us] want to be astronauts (engineer), some want to be pilots
(engineer) and some want to be an escort service operators (better
than engineer).
:-)

>
> It's my experience that good tech writers are actually harder to
> find than good engineers.

That is true and proven everyday in any EE's life.
And it ought to be so - the "food chain" dictates it.
One data sheet is read by thousands, created by few.
You need one sharp group of writers to come up with 500+ pages data sheet.
An engineer (or group of them) design a widget that millions are
produced and used, how well - it depends (i.e. blinking "12:00" on VCR
or intuitive iPod UI).
It is a major mind-shift to think about an engineer as a consumer of
silicon part. You may buy a [quality] hammer which comes with
"consumer questionaire".
But...have you ever - anyone - been asked "what do you think about our
data sheets/documentation?", or "tell us what to improve/correct"?
Most questions start:
"What is the EAU of this component?", the higher number is answered
the more attention is given.
> I guess it's a matter of opinion on whether it takes more
> intelligence to write clear, lucid and accurate documents than
> engineer products that actually work as advertised :-)

Hm.
If I gave you a perfectly debugged SoC without a sheet of information
my guess is that would be useless.
OTOH, if I gave you SoC with [some] bugs, but every *known* anomaly
documented, you could do at least something.
And there are extremes, of course, such as a combination of those two
above.
It takes it all, every part is important no matter what. And to master
the constantly shifting balance is not easy.
I find ARM documentation superior, in all three Fs (form, fit, function).
It surely helped that they sold billions of 'em chips.
Roger

>
> Brendan
> Start a New Thread