Re: [ECOS] Atmel Dataflash driver in combination with AT91SAM7SE512

["Tom Deconinck" <t dot deconinck at gmail dot com>]

On 10/24/07, Tom Deconinck <t.deconinck@gmail.com> wrote:
> On 10/23/07, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Tue, Oct 23, 2007 at 02:38:07PM +0200, Tom Deconinck wrote:
> > > Hi,
> > >
> > > I'm currently working on porting eCos to support the Atmel
> > > AT91SAM7SE-EK board. This board hosts the Atmel AT91SAM7SE512, which
> > > is very similar to the AT91SAM7S which is already supported. The main
> > > differences are the support for an EBI (external bus interface) to
> > > interface all kind of memory devices and the incorporated SDRAM
> > > controller.
> > > I'm using the normal eCos branch enhanced with the flash_v2 branch extensions.
> > >
> > > I was playing around with the SPI peripheral and an Atmel AT45DB041B
> > > and the dataflash driver. The AT91SAM7SE512 forces me to pick a
> > > certain SPI mode, so I configured the controller to use SPI mode 0
> >
> > As far as i can remember, the SAM7 supports all modes and each device
> > can configure its own mode. What is the reason you cannot use the mode
> > the opcodes are valid for?
> >
> >     Andrew
> >
> The reason seems to be my Beagle I2C/SPI analyzer. If I disconnect it,
> I can get it working with the opcodes present in the dataflash driver.
> If I hook it up, it seems to screw up the data on MISO unless I hard
> configure the SPI bus to either mode 0 or 3. I'm rather puzzled, but
> that seems to be it...
>
> I also had an issue with the df_read_status function: the returned
> status struct got "scrambled".
> I'll try to explain what I have seen.
> The df_read_status function reads out the dataflash status register
> and returns that byte as a casted status bitfield struct.
> When I diag_printf the fields of the status struct inside
> df_read_status all values are as expected. In my case the status
> register reads 0x9C, giving me a device id of 0x07 in the status
> struct, which corresponds with the AT45DB041B that I'm using.
> But when I check the status struct that is returned by df_status_read
> in df_detect_device, the device_id is 0x02 all of the sudden, causing
> the dataflash init to fail.
>
> The original df_read_status:
>
> {
>  cyg_spi_device  *spi_dev    = dev->spi_dev;
>     const cyg_uint8  cmd_buf[2] = { DF_STATUS_READ_CMD, 0 };
>     cyg_uint8        rx_buf[2];
>     df_status_t     *p_status;
> df_status_t              status;
>
>    cyg_spi_transaction_transfer(spi_dev, true, 2, cmd_buf, rx_buf, true);
>
>    status = (df_status_t*) &rx_buf[1];
>
>    return *status;
>

Sorry, I was a bit to eager to send.

I have altered df_read_status as follows:

static df_status_t
df_read_status(cyg_dataflash_device_t *dev)
{
cyg_spi_device  *spi_dev    = dev->spi_dev;
const cyg_uint8  cmd_buf[2] = { DF_STATUS_READ_CMD, 0 };
cyg_uint8        rx_buf[2];
df_status_t     *p_status;
df_status_t		 status;

cyg_spi_transaction_transfer(spi_dev, true, 2, cmd_buf, rx_buf, true);

p_status = (df_status_t*) &rx_buf[1];

status.reserved = p_status->reserved;
status.device_id = p_status->device_id;
status.compare_err = p_status->compare_err;
status.ready = p_status->ready;

return status;
}
and now it returns the correct values. Again, I'm puzzled... ;)

I'm using the GNU ARM cross compiler 3.2.1.
Anyone any ideas what's causing this?

Regards,
Tom

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss