Command Sketch: Flash access not stable

[aerialist]

Just got 2.7'' Dev board from Adafruit and hooked up to Arduino Uno. Demo sketch works very nice!

With Command Sketch, I get different result for 'l' search for non-empty sector command even though the commands were issued one after another. e.g.

---

Command: f FLASH chip detected OK FLASH: manufacturer = c2 device = 2014

Command: l 00 01 02 03 04 05 06 07 08 09 0a 0b 10 11 12 13 16 17 20 21

Command: f FLASH chip detected OK FLASH: manufacturer = c2 device = 2014

Command: l 00 01 02 03 04 05 06 07 08 09 10 11 12 13 16 17 20 21

Command: f unsupported FLASH chip FLASH: manufacturer = 00 device = 0000

Command: l 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 10 11 12 13 16 17 20 21

Command: f FLASH chip detected OK FLASH: manufacturer = c2 device = 2014

Command: l 00 01 02 03 04 05 06 07 08 09 0a 10 11 12 13 16 17 20 21

---

And I do often get "unsupported FLASH chip" message for 'f' command. Still I do sometimes get 'FLASH chip detected OK' message as well.

Uploading an image to an empty sector works fine. But erasing a non-empty sector, uploading to it and displaying it often result in corrupted image.

Any advice what to check to make flash access stable?

My unit's label reads "MEM027BS***" thus I believe using EPD_V230_G2 example is correct. A bit strange thing is that it doesn't have 'r' remove image command described on rePaper document.

[hxw]

Your label does indicate V230_G2 (see: http://www.pervasivedisplays.com/products/label_info ). Would you confirm that this is an "extension board-05". (I have not got around to checking the FLASH after I refactored all the drivers ready for the new V231_G2)

How are you uploading images? (using the xbm samples?) On the corruption:

• What does it look like?
  • all/mostly black would indicate data is sticking high
  • all/mostly white would indicate data is sticking low
• You did account for 2.7" taking two sectors

The reason for the missing 'R' command is that the V230 protocol is very different from the V110 and V231 in that it dos not erase the old image before writing the new image.

[aerialist]

Thank you for your attention, hxw! Yes, my dev board is indeed "extension board-05". I'm uploading the xbm samples in Image folder.

Now I know the problem better. The problem is that the erase command e does not work properly. Thus uploading to an empty sector succeeds but erasing (say e00 and e01) & uploading (u00) to non-empty sector results in corrupted image i.e. the newly uploaded image is combined with previous image, resulting mostly white screen.

I modified flash.cpp and flash.h to issue Chip Erase command. And entire FLASH is set to 0xFF correctly. Any idea why e does not work?

[aerialist]

Well, it looks the 'e' erase sector command does work once in a few times... So I suspect there is some loose connection. I close the issue for now and get wirings soldered. Thanks for your support!

[hxw]

I have revised the busy waiting logic, as I was receiving the occaisional flash info as all zero.

The list command would also pick up a particular erased sector as not erased and dump would show some leading zero data. My tests were:

1. use 'f' command several times after an 'l' command - occaisionaly first one would be all zero
2. use 'f' command after 'i0' and 'i1' (containing image data) - occaisionaly first one would be all zero

After the update I did not see this effect, though I did not have much time to test further.

Would you update and see if the new code works on your board.

[aerialist]

Thank you for the update, hxw! I confirmed that the 'f' command and 'l' commands work reliably now. Excellent!

[hxw]

Thanks for testing, I will close this

[zeroepoch]

I'm also observing this exact same behavior with the same display (matching serial prefix) and the same extension board 05. The erase command does not appear to do anything. I get the same data back when doing a dump after an erase. The flash loader example works fine and the code sequence appears to be similar which is a bit strange. Also the list command is showing sectors that are empty as non-empty. Uploading an image which should take 2 sectors only updates the first sector resulting in a corrupted image for the last 1/3 of the screen. I have the latest commit as of today (2c399e89b94b6a7befc0e2f6732d2934de9acbaf). Did the fix you mentioned ever get committed?

[zeroepoch]

I think the changes mentioned earlier were committed in 81ec65e767c034927ddc1068b5439f8c179ff277 but I already had these changes and this doesn't seem to improve anything for me. I'm using the included male/male headers to jumper the cables to the Uno which seems to work fine for all other examples.

[zeroepoch]

Sorry for all the comments here, but hopefully these updates give you some idea what's going on. I wonder if the erase works at all even in the flash loader as opposed to just overwriting the image each time which has the same end effect. In terms of writing to the FLASH I see in the flash loader it uses

EPD_FLASH.write_from_progmem(address, p, EPD_FLASH_PAGE_SIZE);

Which writes 128 bytes at a time I think. The command example just uses

EPD_FLASH.write(address, buffer, count);

I tried to change it to write_to_progmem and it got worse. I didn't try increasing the buffer size from 16 to 128 yet. I wonder if waiting for the serial data causes some sort of timing issue that results in the different behavior. Though despite read/erase not appearing to work it does display part of the image correctly so something is being written correctly.