cancel
Showing results for 
Search instead for 
Did you mean: 

STR710F Flash and SPI facts

rasty
Associate II
Posted on December 26, 2007 at 10:28

STR710F Flash and SPI facts

4 REPLIES 4
rasty
Associate II
Posted on December 26, 2007 at 05:28

Hi *.*,

I’d like to share my experience with STR710F2 and get confirmation (or better disapproval to my findings).

SPI:

1. Old fact: In slave mode SS pin must be configured as input and connected to VCC.

I’ve figured out that SD flash connected over SPI is terribly slow. Further investigations show that:

1. Maximum effective SPI clock is 8 Mhz (48mhz/6). Really disappointing!

2. There is a ~3uSec gap between SPI clock bursts (I work in 8-bit mode). FIFO didn’t help – still gaps. Did anyone see that?

Internal Flash:

1. It is almost impossible to erase flash via JTAG if application does not have busy loop at the starting point. Pretty weird, but somehow mentioned in documentation.

2. Sometimes it is impossible to erase flash by the software – it just locks itself. Neither Write, Readout nor Debug un-protection help. It is still possible to reprogram it by JTAG, but it does not remove this lock. I spent half day playing with ST API functions and finally replaced the CPU.

3. It is not possible to erase/write to Data flash (B1) from Code Flash (B0) - I expected something like that, however documentation explicitly mentions that data Flash can be reprogrammed from application running from B0. FLASH_Erase simply hangs – documentation does not contain any hint that it must run from RAM.

kleshov
Associate II
Posted on December 26, 2007 at 08:44

I can't comment on SPI since I don't have a use for it. I can comment on internal flash though.

1. I've never had problems with erasing via JTAG. Sometimes it's difficult to connect via JTAG, apparently when program in flash does strange things. I've used IAR EWARM as well as OpenOCD with a wiggler.

2. I've never experienced flash locking. I don't need the flash protection feature, so I don't touch it.

3. I use writing to bank1 from code in bank0 routinely to implement EEPROM emulation. There are two caveats. First: the very first flash operation after power-up must be run from RAM, as described in the manual. I do a dummy write for that purpose (write the contents of a word in flash onto itself). Second: the flash end-of-write interrupt is broken, better don't use it. It's been discussed in this forum.

rasty
Associate II
Posted on December 26, 2007 at 10:14

Few more finding

4. It appears that 8-bit BSPI mode reduces SPI bandwidth to half. It looks like 16-bit shift register clocked 16 times anyway, while first 8 pulses are masked out in the chip. It is not immidiately clear from the doc.

5. For some reason, Read-After-Write access in 8-bit mode (appears in virtually any example of SD card access) reduces SPI utilization to nearly 25%. Some explanation from ST would help.

rasty
Associate II
Posted on December 26, 2007 at 10:28

volius,

Interesting...

I copied Erase procedure to RAM, but didn't consider to do that same to Unprotect routine.

I'll try dummy write as you recomend.