SST26VF064B Library… help?

Hi,

Has anyone managed to get the SST26VF064B flash to work on the STM32duino?
I’ve managed to get it detected and the reading part seems to be OK (SPI bus is OK and I can read the ID correctly) but I can’t write on it…

The results from running the test code from SerialFlash library:
Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: BF 26 43
Part Nummber: SST26VF064
Memory Size: 1048576 bytes
Block Size: 65536 bytes
0x05 = 0
0x35 = A
0x72 = 0
0x42 = FF

Reading Chip...
Reading...
addr = 0, data = FF FF FF FF FF FF FF FF
addr = FF8, data = FF FF FF FF FF FF FF FF
addr = 1000, data = FF FF FF FF FF FF FF FF
(....)
addr = FFFF8, data = FF FF FF FF FF FF FF FF

Writing 512 signatures
error writing signature at 0
Read this: FF FF FF FF FF FF FF FF
Expected: 00 00 00 00 15 F5 95 4B

Tests Failed :{

The flash chip may be left in an improper state.
You might need to power cycle to return to normal.


According to the datasheet.

The WP# is used in conjunction with the WPEN and IOC bits in the Configuration register to prohibit write operations
to the Block-Protection register. This pin only works in SPI, single-bit and dual-bit Read mode

So it looks like you need to re-read chapter 4 of the datasheet “4.1 Device Protection.” .. and TABLE 4-1: WRITE PROTECTION LOCK-DOWN STATES

Unfortunately I don’t have the device to play with, so that is about as much as I can say on the subject.

That was the first thing I did But seems I need to re-read 4 or 5 more times
But even with WPEN and IOC disabled doesn’t seem to have effect.

I’m trying to copy the code from the microchip example to see if I can get better results.
I’ve tried to erase the full chip but don’t know if it worked correctly because I now read all zeroes…

Stay tuned for the next episode of “Flash wars”

rexnanet wrote:Stay tuned for the next episode of “Flash wars”

I’m still waiting for the next thrilling episode.

@ahull
Wait no more!!!
Here it is:

Raw SerialFlash Hardware Test
Setup configuration register
GlobalBlockProtectionUnlock
Write prot clear
Done

Read Chip Identification:
JEDEC ID: BF 26 43
Part Nummber: SST26VF064
Memory Size: 1048576 bytes
Block Size: 65536 bytes
STATUS 0x05 = 0
CONFIG 0x35 = A

Reading Chip...
Reading...
addr = 0, data = FF FF FF FF FF FF FF FF
(..)
addr = FFFF8, data = FF FF FF FF FF FF FF FF

Writing 512 signatures

Double Checking All Signatures:
all 512 signatures read ok

Checking Signature Pairs
all 255 signature pairs read ok

Checking Read-While-Write (Program Suspend)
write 256 bytes at 256
write time was 1369 microseconds.
read-while-writing: 00 00 00 00 15 F5 95 4B
test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
erase time was 18573 microseconds.
erase correctly erased 65536 bytes
read-while-erasing: 00 00 00 00 15 F5 95 4B
test passed, good read while erasing

All Tests Passed :-)

Test data was written to your chip. You must run
EraseEverything before using this chip for files.

The story is staring to get pretty interesting.

Keep us posted with your progress.

…on the quest to have the serial upload python script working in Windows… (yes, I said it… Windows…)
Python – installed.
Pyserial – installed.
Testing… not yet

Let us know how the testing goes.

What is the purpose of this mysterious device?

BTW, I’ve used this library in the past to access different flavours of WinBond SPI Flash :
https://github.com/LowPowerLab/SPIFlash

ahull wrote:The story is staring to get pretty interesting.

Keep us posted with your progress.

zmemw16 wrote:ahull wrote:

got the next generation interested? st is next

I love Python !
I’m using it since more than 16 years (almost never use Perl any more since then)
What is exactly the problem you’re facing ?

martinayotte wrote:I love Python !
I’m using it since more than 16 years (almost never use Perl any more since then)
What is exactly the problem you’re facing ?

martinayotte wrote:
What is exactly the problem you’re facing ?

Did you have first uploaded the CopyFromSerial sketch into your STM ?

(For the time printing and divide by zero, it is probably simply because your file is so small, it took less than a second)

martinayotte wrote:Did you have first uploaded the CopyFromSerial sketch into your STM ?

For debugging, I would rather use a second serial port to do some debug prints and leave the first one for the CopyFromSerial functionalities.

Yeeeaaaaaahhhh….
That might become the “last resort” option
I was hoping to keep this as simple as possible but that might seem the best option…

Going to try the “last resort” option

But I have a question:
What is the Serial-UART correlation?

“Serial” is used by the USB serial connection.
I’ve tried to use “Serial2” and connected the serial adapter to USART2 (PA_2 and PA_3 pins) but got no output. Then got to switch attention to other things and stopped there…

I’ve found this code from Roger but haven’t checked whether the constant is defined or not:
/*
* Roger Clark
*
* 2015/05/28
*
* Moved definitions for Hardware Serial devices from HardwareSerial.cpp so that each board can define which Arduino "Serial" instance
* Maps to which hardware serial port on the microprocessor
*/

#ifdef SERIAL_USB
DEFINE_HWSERIAL(Serial1, 1);

DEFINE_HWSERIAL(Serial2, 2);

DEFINE_HWSERIAL(Serial3, 3);
#else
DEFINE_HWSERIAL(Serial, 1);

DEFINE_HWSERIAL(Serial1, 2);

DEFINE_HWSERIAL(Serial2, 3);
#endif

New episode:

Finally got USART2 to work.
After making a test sketch that was successful, I returned to the original sketch and…tada… it works
Did I make any modification for it to work… no. But it did, so next…

Debugging episodes:

1- After adding debug found out the first problem:
I made a test text file with some letters in it and named it “test.txt”.
Then I found that on the sketch the only letters allowed are CAPS!!!! I was like “what?!?!?!? why?????? It’s not that difficult to add and would save me a lot of work…”
So I added it to the sketch… (but also renamed the file to move forward, just in case…)

2- After some small mods, the sketch would end but nothing was written…
The Flash Buffer is set to 4096 bytes but the USB Buffer is set to 128 bytes. The file had 908 bytes and after 128 bytes the sketch moved on and ended without nothing written on the flash.
Still haven’t found out what is going on but moved the USB Buffer to 4096 and the sketch ended successfully.

Uploaded the “read files from flash” sketch I made and BAAAAMMM the file got written!!!

This is a big step forward

Now somethings still need to be done:
1- find out what is the deal with the USB buffer size, because I suspect I can’t write files bigger than 4096 bytes with this issue…
2- test with multiple files being written.
3- test the speed!!!!
4- connect to the ILI9341 and get some pictures going!!!!

Edit:
1- find out what is the deal with the USB buffer size, because I suspect I can’t write files bigger than 4096 bytes with this issue… – haven’t looked at this
2- test with multiple files being written. – OK
3- test the speed!!!! – Working OK @ SPI=36Mhz. Overclock still to come
4- connect to the ILI9341 and get some pictures going!!!! – “most probably” OK (Got some picture showing but the image was not ok in the flash because of the “Esc” stuff on the sketch. I’ll explain that later…

So, image artifacts weren’t related only to the “ESC” byte detection on the script and sketch but also with some data loss on the serial connection.

Further investigation on the way: http://www.stm32duino.com/viewtopic.php … 985#p18985

After solving the issue with Seria.readBytes() that is missing data randomly (still going to try with Serial.read(data,len) ) by using Serial.read() instead and reading one byte at a time, the first image has arrived!!

Performance is still not perfect (245ms to load the full image vs 34ms for a fillscreen) but I still have to add DMA to SerialFlash and try again. Still the minimum theoretical time would be 68ms (34ms loading from flash and 34ms writing to display) around 15fps. Then maybe 30fps with overclok. Should look ok

I also tried overclocking but I got “File not found” error with more than 8Mhz overclock. This shouldn’t happen unless for some reason the read command used is the “normal” read (cmd= 0x03 -> 40Mhz max SPI) which I’m not using (fast read cmd= 0x0B -> 104Mhz max SPI). Have to investigate…

rexnanet wrote: Still the minimum theoretical time would be 68ms (34ms loading from flash and 34ms writing to display) around 15fps.

There’s 2 approaches possible:
1 – use 2 SPI buses: SPI1 for the display and SPI2 for the flash.
This would allow to use direct DMA from one to another. But SPI2 runs at half the speed of SPI1 so this would slow down things a bit (18Mhz max).

2- use SPI1 for both display and flash.
This allows for faster SPI (36Mhz) but needs intermediate buffering and would take 2x as long.
Ultimately this would lead to half the speed being equal performance to (1) but I plan to try a different approach that takes advantage from the fast clock.

The 3rd approach
I’m planing to, after setting the display and point to the start of the file on the flash, redirect the SO of the Flash to the SI of the display and then issue a transfer to provide the clock signal for the transaction.
This will allow to transfer the image directly to the display at maximum speed (ultimately @64Mhz with overclock ) allowing almost 60fps speeds !!!

The only downside is that I have to add a multiplexer to the circuit.

You could see if you can get hold of a cheap GD32F103C. I added a setting for 120Mhz main clock, which would give 60Mhz on SPI (though I don’t know if the display would cope with this, I have had issues with the GD32 on SPI, which I think are related to it running to fast for a lot of devices)

Also GD32 runs the program from shadow RAM, not Flash, so code runs generally faster as well (I think the STM32 is running with 2 wait states between Flash read’s but the GD32 has none), In practice because of CPU core caching and pipelining and predictive branching etc, this doesn’t mean the GD32 runs 3 times as fast, but it is noticably faster

(I’m sure I posted the Dhrystone tests, which give an indication of the difference in speed)

But, GD32 boards seem to be difficult to get hold of, I can’t see any GD32 boards on AliExpress or eBay at all.

Yes, I’ve tried to get a hold of a board but it’s not easy… So I gave up.

With overclock I can get the STM32 to run at 128Mhz and SPI at 64Mhz
I’ve posted some videos on that :
https://www.youtube.com/watch?v=Dui-L7S7nS0
https://www.youtube.com/watch?v=VOxv87-hZt8

The display (ILI9341) handles that well. Only at 80Mhz I couldn’t get it to work (using ESP8266) but I’m still going to try with shorter wires. I was testing with 20cm dupont wires, I have some 10cm now.

My next chip test will be the ESP32… it has lots of everything RAM, speed, cores, flash, pins (…) ,WiFi, BT LE… and less of one thing: the price
It will smash everything else… lol

But for now continue with image loading

New results:

-Added DMA support on flash read. Now full screen image takes 90ms “more nicer”!

– Somehow Portrait and Landscape modes have different byte order… I was testing in Landscape and when I loaded a Portrait image the colors were all messed up. That’s not nice!!! Had to make some changes to detect the positioning and write to the display accordingly…

I’ve also made an example code that goes through all the memory and displays all the images available Will show some cool stuff later on

Didn’t make any video on this…but soon will be available

If my calculations are correct, 90 ms gives you 11.11 fps, which is pretty impressive.

And now the videos

Displaying a set of demo images:
https://www.youtube.com/watch?v=F2ZsxGfDOyc

And a loop I made from a demo video:
https://www.youtube.com/watch?v=bMKZ26XmYWQ

I haven’t speed up thing yet. Still have to test overclock again…
I’m getting around 88ms per image, around 11fps.