Thanks for the suggestion, we did in fact tested one of those flash ICs on
isolation and worked the same.

Nevertheless after a long weekend we found problem was in software library:
the "SPI delete section" command had an extra bogus byte nobody noticed
before, and that was not an issue for silicon in earlier batches or even
most units in the last batch.

Surprisingly though, that bogus byte indirectly caused the next SPI
commands to not work as expected in some units in the new batch, so we just
uncovered an old bug that was irrelevant till latest silicon received.
Being indirect issue was really tricky to isolate.

So all set... just live and learn.

Ariel Rocholl


On Sat, Jun 13, 2015 at 2:39 AM, Jason White <
whitewaterssoftwareinfo@gmail.com> wrote:

> I don't have anything helpful to say, you make it sound like a
> hardware errata, but could it be something about the board you putting
> them on?
>
> Do you have power supply decoupling for your memory? (30mA write current)
>
> Have you been able to reproduce the problem off of your problematic
> board? It should take little effort to solder one or two bad memories
> to a breakout board to run them through their paces. I would think
> that would make issue much more clear cut.
>
>
>
> On Thu, Jun 11, 2015 at 8:42 PM, arocholl <foros@arocholl.com> wrote:
> > Hi there, we are experiencing problems with a 16Mbit SPI Flash (exact
> part
> > is SST25VF016B - datasheet
> > http://ww1.microchip.com/downloads/en/DeviceDoc/20005044B.pdf)
> >
> >
> >
> > The auto address increment command AAI seems to work fine for all 4KB
> memory
> > sectors except first one and last one. About 20% of the parts do not
> write
> > any byte in the first sector, and just write some in the last sector.
> Other
> > parts in a 2K batch are ok. Writing in byte mode (one byte at a time)
> seems
> > to work fine in all batch.
> >
> >
> >
> > We already looked at boundary conditions in our software and seems to b=
e
> ok.
> > Also looked into bus speed, write-enable status, flash wearing, etc.
> >
> >
> >
> > We are runnig out of clues. Anyone here experienced problems of this ki=
nd
> > with SPI Flash products from MCP?
> >
> >
> >
> > Note: Unfortunately there is no errata documentation for this part we
> could
> > find, not sure if because it has no known bugs or, more likely, because
> it
> > comes from SST acquired brand that may have different team and
> documentation
> > protocols.
> >
> >
> > TIA
> >
> > ----
> > Ariel Rocholl
> >
> >
> >
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
>
>
>
> --
> Jason White
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.