We've just had a new batch of boards built with what appears to be
Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
then AU on the next line, then B on the next line where this line was
previously A.
The Rev A parts have been used for some time on this and other
products and have been performing well. With the Rev B parts we're
seeing a problem with the SPI port. Everything else (USB, serial,
Timer Counters, PWM) seems to be working correctly. So far this is
the first product that we've built that have the Rev B parts on it.
The problem we're seeing is that the MOSI output pin appears to be
sending all 1's when using the PDC, though I haven't verified that
polling works, either (I'm working on checking that). The SPI chip
select is working properly, the SPI clock signal is being generated
correctly, and the MISO input appears to be reading data correctly.
Replacing the Rev B part with a Rev A part using the same firmware
works and it's a 100% failure with the Rev B parts.
I'm hoping that this is just some sort of configuration bug that we
happened to get lucky that it worked on the previous rev, but so far I
haven't found the cause.
Anyone else seen this?
Thanks,
Cliff
Any one having problems with Rev B AT91SAM7S256 parts?
Started by ●August 6, 2008
Reply by ●August 6, 20082008-08-06
We're using the same part and our last two runs were the B part. We
use the SPI port extensively through the PDC.
Please what you find out.
--- In A..., "techguy2000" wrote:
> We've just had a new batch of boards built with what appears to be
> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
> then AU on the next line, then B on the next line where this line was
> previously A.
>
> The Rev A parts have been used for some time on this and other
> products and have been performing well. With the Rev B parts we're
> seeing a problem with the SPI port. Everything else (USB, serial,
> Timer Counters, PWM) seems to be working correctly. So far this is
> the first product that we've built that have the Rev B parts on it.
use the SPI port extensively through the PDC.
Please what you find out.
--- In A..., "techguy2000" wrote:
> We've just had a new batch of boards built with what appears to be
> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
> then AU on the next line, then B on the next line where this line was
> previously A.
>
> The Rev A parts have been used for some time on this and other
> products and have been performing well. With the Rev B parts we're
> seeing a problem with the SPI port. Everything else (USB, serial,
> Timer Counters, PWM) seems to be working correctly. So far this is
> the first product that we've built that have the Rev B parts on it.
Reply by ●August 8, 20082008-08-08
Found the problem. When the Rev B SPI controller is reinitialized,
the receive data register comes up as being full. We didn't check for
the receive data regsiter having anything in it before enabling PDC
transfers, so as soon as the receive PDC was enabled the bogus
character (0xff) would get written to the buffer. We use the same
buffer for both transmit and receive, so the first byte of the
transmit message got trashed with the 0xff that was in the receive
data register.
The simple fix is to read the SPI receive data register before
enabling the SPI PDCs to ensure it's empty.
The problem doesn't occur the first time the SPI port is initialized
after reset, only on subsequent initializations. I don't see anything
in our init code that should be causing a receive buffer full
indication and the Rev A parts work fine, so I think this is a bug of
some sort in the SPI port state machine.
--- In A..., "techguy2000" wrote:
> We've just had a new batch of boards built with what appears to be
> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
> then AU on the next line, then B on the next line where this line was
> previously A.
>
> The Rev A parts have been used for some time on this and other
> products and have been performing well. With the Rev B parts we're
> seeing a problem with the SPI port. Everything else (USB, serial,
> Timer Counters, PWM) seems to be working correctly. So far this is
> the first product that we've built that have the Rev B parts on it.
>
> The problem we're seeing is that the MOSI output pin appears to be
> sending all 1's when using the PDC, though I haven't verified that
> polling works, either (I'm working on checking that). The SPI chip
> select is working properly, the SPI clock signal is being generated
> correctly, and the MISO input appears to be reading data correctly.
> Replacing the Rev B part with a Rev A part using the same firmware
> works and it's a 100% failure with the Rev B parts.
>
> I'm hoping that this is just some sort of configuration bug that we
> happened to get lucky that it worked on the previous rev, but so far I
> haven't found the cause.
>
> Anyone else seen this?
>
> Thanks,
> Cliff
>
the receive data register comes up as being full. We didn't check for
the receive data regsiter having anything in it before enabling PDC
transfers, so as soon as the receive PDC was enabled the bogus
character (0xff) would get written to the buffer. We use the same
buffer for both transmit and receive, so the first byte of the
transmit message got trashed with the 0xff that was in the receive
data register.
The simple fix is to read the SPI receive data register before
enabling the SPI PDCs to ensure it's empty.
The problem doesn't occur the first time the SPI port is initialized
after reset, only on subsequent initializations. I don't see anything
in our init code that should be causing a receive buffer full
indication and the Rev A parts work fine, so I think this is a bug of
some sort in the SPI port state machine.
--- In A..., "techguy2000" wrote:
> We've just had a new batch of boards built with what appears to be
> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
> then AU on the next line, then B on the next line where this line was
> previously A.
>
> The Rev A parts have been used for some time on this and other
> products and have been performing well. With the Rev B parts we're
> seeing a problem with the SPI port. Everything else (USB, serial,
> Timer Counters, PWM) seems to be working correctly. So far this is
> the first product that we've built that have the Rev B parts on it.
>
> The problem we're seeing is that the MOSI output pin appears to be
> sending all 1's when using the PDC, though I haven't verified that
> polling works, either (I'm working on checking that). The SPI chip
> select is working properly, the SPI clock signal is being generated
> correctly, and the MISO input appears to be reading data correctly.
> Replacing the Rev B part with a Rev A part using the same firmware
> works and it's a 100% failure with the Rev B parts.
>
> I'm hoping that this is just some sort of configuration bug that we
> happened to get lucky that it worked on the previous rev, but so far I
> haven't found the cause.
>
> Anyone else seen this?
>
> Thanks,
> Cliff
>
Reply by ●August 11, 20082008-08-11
I checked with a buddy of mine who works as an FAE for Atmel and he
provided the following information:
-----
Bill,
Could you suggest that he try 2 software resets of the SPI module and
see if it fixes his issue? I got this from the factory:
It seems that the state machine for revB version needs to have 2 spi
software reset to properly reset the state machine.
So if the customer is doing the following:
AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN | AT91C_SPI_SWRST;
He may try now:
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
------
Regards
-Bill Knight
R O SoftWare
techguy2000 wrote:
> Found the problem. When the Rev B SPI controller is reinitialized,
> the receive data register comes up as being full. We didn't check for
> the receive data regsiter having anything in it before enabling PDC
> transfers, so as soon as the receive PDC was enabled the bogus
> character (0xff) would get written to the buffer. We use the same
> buffer for both transmit and receive, so the first byte of the
> transmit message got trashed with the 0xff that was in the receive
> data register.
>
> The simple fix is to read the SPI receive data register before
> enabling the SPI PDCs to ensure it's empty.
>
> The problem doesn't occur the first time the SPI port is initialized
> after reset, only on subsequent initializations. I don't see anything
> in our init code that should be causing a receive buffer full
> indication and the Rev A parts work fine, so I think this is a bug of
> some sort in the SPI port state machine.
>
> --- In A..., "techguy2000" wrote:
>>
>> We've just had a new batch of boards built with what appears to be
>> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
>> then AU on the next line, then B on the next line where this line was
>> previously A.
>>
>> The Rev A parts have been used for some time on this and other
>> products and have been performing well. With the Rev B parts we're
>> seeing a problem with the SPI port. Everything else (USB, serial,
>> Timer Counters, PWM) seems to be working correctly. So far this is
>> the first product that we've built that have the Rev B parts on it.
>>
>> The problem we're seeing is that the MOSI output pin appears to be
>> sending all 1's when using the PDC, though I haven't verified that
>> polling works, either (I'm working on checking that). The SPI chip
>> select is working properly, the SPI clock signal is being generated
>> correctly, and the MISO input appears to be reading data correctly.
>> Replacing the Rev B part with a Rev A part using the same firmware
>> works and it's a 100% failure with the Rev B parts.
>>
>> I'm hoping that this is just some sort of configuration bug that we
>> happened to get lucky that it worked on the previous rev, but so far I
>> haven't found the cause.
>>
>> Anyone else seen this?
>>
>> Thanks,
>> Cliff
provided the following information:
-----
Bill,
Could you suggest that he try 2 software resets of the SPI module and
see if it fixes his issue? I got this from the factory:
It seems that the state machine for revB version needs to have 2 spi
software reset to properly reset the state machine.
So if the customer is doing the following:
AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN | AT91C_SPI_SWRST;
He may try now:
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
------
Regards
-Bill Knight
R O SoftWare
techguy2000 wrote:
> Found the problem. When the Rev B SPI controller is reinitialized,
> the receive data register comes up as being full. We didn't check for
> the receive data regsiter having anything in it before enabling PDC
> transfers, so as soon as the receive PDC was enabled the bogus
> character (0xff) would get written to the buffer. We use the same
> buffer for both transmit and receive, so the first byte of the
> transmit message got trashed with the 0xff that was in the receive
> data register.
>
> The simple fix is to read the SPI receive data register before
> enabling the SPI PDCs to ensure it's empty.
>
> The problem doesn't occur the first time the SPI port is initialized
> after reset, only on subsequent initializations. I don't see anything
> in our init code that should be causing a receive buffer full
> indication and the Rev A parts work fine, so I think this is a bug of
> some sort in the SPI port state machine.
>
> --- In A..., "techguy2000" wrote:
>>
>> We've just had a new batch of boards built with what appears to be
>> Rev B parts and are seeing a problem. The markings are AT91SAM7S256,
>> then AU on the next line, then B on the next line where this line was
>> previously A.
>>
>> The Rev A parts have been used for some time on this and other
>> products and have been performing well. With the Rev B parts we're
>> seeing a problem with the SPI port. Everything else (USB, serial,
>> Timer Counters, PWM) seems to be working correctly. So far this is
>> the first product that we've built that have the Rev B parts on it.
>>
>> The problem we're seeing is that the MOSI output pin appears to be
>> sending all 1's when using the PDC, though I haven't verified that
>> polling works, either (I'm working on checking that). The SPI chip
>> select is working properly, the SPI clock signal is being generated
>> correctly, and the MISO input appears to be reading data correctly.
>> Replacing the Rev B part with a Rev A part using the same firmware
>> works and it's a 100% failure with the Rev B parts.
>>
>> I'm hoping that this is just some sort of configuration bug that we
>> happened to get lucky that it worked on the previous rev, but so far I
>> haven't found the cause.
>>
>> Anyone else seen this?
>>
>> Thanks,
>> Cliff
Reply by ●August 11, 20082008-08-11
For what it is worth, we are using AT91SAM9263 rev B parts, which has
the same SPI controller I believe as the SAM7 parts, and we had to do
this exact same thing to get the SPI controller to work on the 9263 rev
B part. It appears to be new, undocumented errata. We noticed that
Atmel added this double reset change into the new at91boot code for the
9263 rev b. as well.
Jeff
On Mon, 2008-08-11 at 10:18 -0500, Bill Knight wrote:
> I checked with a buddy of mine who works as an FAE for Atmel and he
> provided the following information:
>
> -----
> Bill,
> Could you suggest that he try 2 software resets of the SPI module and
> see if it fixes his issue? I got this from the factory:
>
> It seems that the state machine for revB version needs to have 2 spi
> software reset to properly reset the state machine.
>
> So if the customer is doing the following:
> AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN | AT91C_SPI_SWRST;
>
> He may try now:
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
> ------
>
> Regards
> -Bill Knight
> R O SoftWare
>
> techguy2000 wrote:
> > Found the problem. When the Rev B SPI controller is reinitialized,
> > the receive data register comes up as being full. We didn't check
> for
> > the receive data regsiter having anything in it before enabling PDC
> > transfers, so as soon as the receive PDC was enabled the bogus
> > character (0xff) would get written to the buffer. We use the same
> > buffer for both transmit and receive, so the first byte of the
> > transmit message got trashed with the 0xff that was in the receive
> > data register.
> >
> > The simple fix is to read the SPI receive data register before
> > enabling the SPI PDCs to ensure it's empty.
> >
> > The problem doesn't occur the first time the SPI port is initialized
> > after reset, only on subsequent initializations. I don't see
> anything
> > in our init code that should be causing a receive buffer full
> > indication and the Rev A parts work fine, so I think this is a bug
> of
> > some sort in the SPI port state machine.
> >
> > --- In A..., "techguy2000" wrote:
> >>
> >> We've just had a new batch of boards built with what appears to be
> >> Rev B parts and are seeing a problem. The markings are
> AT91SAM7S256,
> >> then AU on the next line, then B on the next line where this line
> was
> >> previously A.
> >>
> >> The Rev A parts have been used for some time on this and other
> >> products and have been performing well. With the Rev B parts we're
> >> seeing a problem with the SPI port. Everything else (USB, serial,
> >> Timer Counters, PWM) seems to be working correctly. So far this is
> >> the first product that we've built that have the Rev B parts on it.
> >>
> >> The problem we're seeing is that the MOSI output pin appears to be
> >> sending all 1's when using the PDC, though I haven't verified that
> >> polling works, either (I'm working on checking that). The SPI chip
> >> select is working properly, the SPI clock signal is being generated
> >> correctly, and the MISO input appears to be reading data
> correctly.
> >> Replacing the Rev B part with a Rev A part using the same firmware
> >> works and it's a 100% failure with the Rev B parts.
> >>
> >> I'm hoping that this is just some sort of configuration bug that we
> >> happened to get lucky that it worked on the previous rev, but so
> far I
> >> haven't found the cause.
> >>
> >> Anyone else seen this?
> >>
> >> Thanks,
> >> Cliff
>
>
the same SPI controller I believe as the SAM7 parts, and we had to do
this exact same thing to get the SPI controller to work on the 9263 rev
B part. It appears to be new, undocumented errata. We noticed that
Atmel added this double reset change into the new at91boot code for the
9263 rev b. as well.
Jeff
On Mon, 2008-08-11 at 10:18 -0500, Bill Knight wrote:
> I checked with a buddy of mine who works as an FAE for Atmel and he
> provided the following information:
>
> -----
> Bill,
> Could you suggest that he try 2 software resets of the SPI module and
> see if it fixes his issue? I got this from the factory:
>
> It seems that the state machine for revB version needs to have 2 spi
> software reset to properly reset the state machine.
>
> So if the customer is doing the following:
> AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN | AT91C_SPI_SWRST;
>
> He may try now:
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
> AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
> ------
>
> Regards
> -Bill Knight
> R O SoftWare
>
> techguy2000 wrote:
> > Found the problem. When the Rev B SPI controller is reinitialized,
> > the receive data register comes up as being full. We didn't check
> for
> > the receive data regsiter having anything in it before enabling PDC
> > transfers, so as soon as the receive PDC was enabled the bogus
> > character (0xff) would get written to the buffer. We use the same
> > buffer for both transmit and receive, so the first byte of the
> > transmit message got trashed with the 0xff that was in the receive
> > data register.
> >
> > The simple fix is to read the SPI receive data register before
> > enabling the SPI PDCs to ensure it's empty.
> >
> > The problem doesn't occur the first time the SPI port is initialized
> > after reset, only on subsequent initializations. I don't see
> anything
> > in our init code that should be causing a receive buffer full
> > indication and the Rev A parts work fine, so I think this is a bug
> of
> > some sort in the SPI port state machine.
> >
> > --- In A..., "techguy2000" wrote:
> >>
> >> We've just had a new batch of boards built with what appears to be
> >> Rev B parts and are seeing a problem. The markings are
> AT91SAM7S256,
> >> then AU on the next line, then B on the next line where this line
> was
> >> previously A.
> >>
> >> The Rev A parts have been used for some time on this and other
> >> products and have been performing well. With the Rev B parts we're
> >> seeing a problem with the SPI port. Everything else (USB, serial,
> >> Timer Counters, PWM) seems to be working correctly. So far this is
> >> the first product that we've built that have the Rev B parts on it.
> >>
> >> The problem we're seeing is that the MOSI output pin appears to be
> >> sending all 1's when using the PDC, though I haven't verified that
> >> polling works, either (I'm working on checking that). The SPI chip
> >> select is working properly, the SPI clock signal is being generated
> >> correctly, and the MISO input appears to be reading data
> correctly.
> >> Replacing the Rev B part with a Rev A part using the same firmware
> >> works and it's a 100% failure with the Rev B parts.
> >>
> >> I'm hoping that this is just some sort of configuration bug that we
> >> happened to get lucky that it worked on the previous rev, but so
> far I
> >> haven't found the cause.
> >>
> >> Anyone else seen this?
> >>
> >> Thanks,
> >> Cliff
>
>
