<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hallo Stefan,<br>
      anhand des "at" am Ende denke (oder hoffe) ich du sprichst
      deutsch.<br>
      <br>
      Der Chip ist ein 3.3V, ich Depp habe es aber mit dem 5V Adapter
      probiert.<br>
      Daher kann es sein das der Chip nun nicht mehr so toll ist... <span
        class="moz-smiley-s7"><span> :-\ </span></span><br>
      Jetzt verwende ich den 3.3V Adapter den ich mir vorhin schnell
      zusammen gebaut habe.<br>
      Habe den Flash nun mehrmals Veryfied, manchmal geht es manchmal
      nicht.<br>
      Aber wenn der Chip nun einen Knacks hat sind jegliche weitere
      tests zwecklos.<br>
      Der Fehler kommt übrigens immer an einem anderen Ort. Mal hier,
      mal da...<br>
      Läuft etwas unstabil.<br>
      <br>
      <b>Geht:</b><br>
      <i>Reading old flash chip contents... done.</i><i><br>
      </i><i>Verifying flash... VERIFIED.</i><br>
      <br>
      <b>Geht nicht:</b><br>
      <i>Reading old flash chip contents... done.</i><i><br>
      </i><i>Verifying flash... FAILED at 0x00096a02! Expected=0x0b,
        Found=0x47, failed byte count from 0x00000000-0x001fffff: 0x39d</i><br>
      <br>
      oder mit version 0.9.5.2-r1517<br>
      Reading old flash chip contents... done.<br>
      Verifying flash... VERIFY FAILED at 0x00148489! Expected=0x02,
      Read=0x00, failed byte count from 0x00000000-0x001fffff: 0xe9<br>
      <i><br>
        Reading old flash chip contents... done.</i><i><br>
      </i><i>Verifying flash... VERIFY FAILED at 0x0002369b!
        Expected=0x5a, Read=0xc6, failed byte count from
        0x00000000-0x001fffff: 0x39</i><i><br>
      </i><br>
      <br>
      Habe auch versucht den Speed runter zu stellen
      (serprog:dev=/dev/ttyACM0:1500000).<br>
      Was aber nicht funktioniert hat. Wenn ich weiter runter gehe
      bekomme ich einen Sync error:<br>
      <i><br>
      </i><i>Calibrating delay loop... OK.</i><i><br>
      </i><i>Error: cannot synchronize protocol - check communications
        and reset device?</i><i><br>
      </i><i>Error: Programmer initialization failed.</i><br>
      <br>
      An der Kabellänge kann es auch nicht liegen, denn die beträgt
      weniger als 10cm.<br>
      <br>
      Lange Rede kurzer Sinn:<br>
      Ich schaue das ich einen neuen Chip organisieren kann und teste
      damit.<br>
      Bez. es kann auch sein das es am Programmer und gar nicht an
      flashrom liegt!<br>
      <br>
      Eine andere Frage:<br>
      Wiso werden die AT45DBxxx Chips nicht unterstützt? Gibt es da eine
      möglichkeit diese<br>
      zu unterstützen?<br>
      <br>
      Danke für die Hilfe!<br>
      <br>
      Gruss<br>
      <br>
      Marc<br>
      <br>
      <br>
      Am 17.10.2013 11:58, schrieb Stefan Tauner:<br>
    </div>
    <blockquote
      cite="mid:201310170958.r9H9wZFN019914@mail2.student.tuwien.ac.at"
      type="cite">
      <pre wrap="">On Thu, 17 Oct 2013 10:20:47 +0200
Raven <a class="moz-txt-link-rfc2396E" href="mailto:originalraven@hotmail.com"><originalraven@hotmail.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Hello,
here are the test results for "Found Micron/Numonyx/ST flash chip 
"M25P16" (2048 kB, SPI)".
Erase seems to work, but write fails.
I tried it with an Arduino Uno 
(<a class="moz-txt-link-freetext" href="http://www.flashrom.org/Serprog/Arduino_flasher">http://www.flashrom.org/Serprog/Arduino_flasher</a>).
</pre>
      </blockquote>
      <pre wrap="">
Hi and thanks for your report!

I think the most probable causes are 1) a flaky chip, 2) flaky
connections, but I am not sure.

To test for flaky connections please re-read the chip a few times
and compare the results. One way to do that is using the verify
command multiple times:
./flashrom -p serprog:dev=/dev/ttyACM0:2000000 -Vv test.rom 

If it always fails like it did for writing (first byte/failure being
Expected=0x55, Found=0x4b, and a total of 0x8399d unexpected bytes),
then at least the clock, MISO and MOSI connections should be ok.

What happens if you write the same image again? The number of
unexpected bytes seems rather huge to me (more than half a MB) to be
just a flaky chip, but erasing apparently works, so it cant be a simple
write protection. What does the following command print out?
hexdump  -e '/1 "%02X\n"' test.rom | grep -v FF -c
(it should show the number of bytes in test.rom that are not all ones,
i.e. 0xFF).

</pre>
      <blockquote type="cite">
        <pre wrap="">Output is attached.
</pre>
      </blockquote>
      <pre wrap="">
Please do not compress log files in mails here.
</pre>
    </blockquote>
    <br>
  </body>
</html>