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

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> From: Tom Deconinck
> 
> > 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.

This is a situation where I'd manually compile to assembly (-S option), and
then read the generated code. I wouldn't be entirely bowled over if it turns
out there is a code generator bug, when dealing with structures with
bitfields, or returning small structures as values. It's a pretty old
version of the compiler.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


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