Hi Michael, I will stop referring to the "obscure forum":-)
You are right there are very little differences from the 39VF6401B flash to some of its predecessors. I used "Beyond Compare to compare the SST39VF16/32/64-01 and the 39VF640XB specs, and besides 5555H vs 555H and 2AAAH vs 2AAH differences I also noticed another difference between the 39VFXXXX and 39VFXXXXB. Taken from the SST 39VF6401B spec: "This is that some erase command has been swapped(This is for the 39VF6401B): The Sector- (or Block-) Erase operation allows the system to erase the device on a sector-by-sector (or block-byblock) basis. The SST39VF640xB offer both Sector-Erase and Block-Erase mode. The sector architecture is based on uniform sector size of 2 KWord. The Block-Erase mode is based on uniform block size of 32 KWord. The Sector- Erase operation is initiated by executing a six-byte command sequence with Sector-Erase command (50H) and sector address (SA) in the last bus cycle. The Block-Erase operation is initiated by executing a six-byte command sequence with Block-Erase command (30H) and block address (BA) in the last bus cycle. The sector or block address is latched on the falling edge of the sixth WE# pulse, while the command (50H or 30H) is latched on the rising edge of the sixth WE# pulse...." For the SST39VF16/32/64-01 specification the 30H and 50H is swapped is this maybe taken care of by the 2 different command sets already? Is this Block/Sector Erase even being used during the normal flash process? How can I learn more about the commands sets? Sorry for all the questions:-) Regards Flemming -----Original Message----- From: Michael Schwingen [mailto:rincew...@discworld.dascon.de] Sent: 30. december 2009 23:16 To: Flemming Futtrup; openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B external flash Flemming Futtrup wrote: > Hi Michael, > > Thanks for all the comments Good to know that I might be on the track. > > Here are my comments/questions: > >> So something goes wrong when running the programming algorithm on the >> > target. One possible area would be the command-completion check, where > the toggle/error bits differ between manufacturers. > > OK, is it possible to alter/verify this? > You would have to look at the run_algorithm code in the CFI driver and match that against the datasheet for the flash. Remote debugging this might get difficult. >> When running the programming algorithm on target (with working area), >> > can you program the SST39VF6401 flash on the same board? What about a > different flash with command set 02 (eg. Spansion)? > > I don't have the SSTVF396401 flash and I am 90% SW guy so soldering a > new flash onto the board is difficult for me. However if it is the only > way forward I will be able to do it but not until the 5. of January > because of missing equipment. > > > >> The question being: is this a problem with the SST flash, or is this a >> > general problem with target-based programming on the CPU you use? > > The flash programming works fine with the exact same CPU:LPC2468 on an > embedded artist board with SST 39VF3201 flash. The only change I made to > my script is the Flash size as that flash is a 4M. > Hm. From a quick look, I did not see anything strange in the 39VF6401B datasheet that would explain the differences. Unfortunately, the biggest SST flash I have here in my collection is the 39VF3201, so this is no help for you. > kind of trouble as some of the other people I read about are having? > >> I do not know what kind of trouble you are talking about - I can't >> > remember any unresolved CFI/non-CFI flash problems related to command > sets on this list in the lasts few months. Do you have a pointer to such > a discussion? > > Ohh maybe I got it wrong. I was referring to posts similar to this: > http://forum.sparkfun.com/viewtopic.php?t=4272 > Hm - are you serious? You use a post on some obscure web forum, more than 3 years out of date, as reference? Even if a current problem is described there, how should the OpenOCD developers know about it? Support for AMD/Spansion CFI flash has been in OpenOCD for quite some time, and works great - otherwise, you would not be able to program the 39VF3201, either. I just pulled current openocd-git and plugged an EON EN29LV640L into my development board (I have sockets for those TSOP48 flashs - too bad Yamaichi stopped making them when ROHS came up): JTAG tap: ipx42x.cpu tap/device found: 0x19277013 (mfg: 0x009, part: 0x9277, ver: 0x1) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled (processor reset) XSCALE_CTRL (/32): 0x000000F8 Flash Manufacturer/Device: 0x007f 0x227e configuration specifies 0x200000 size, but a 0x800000 size flash was found flash 'cfi' found at 0x50000000 > uboot protect: cfi primary command set 2 unsupported cleared protection for sectors 0 through 10 on flash bank 0 auto erase enabled wrote 262144 bytes from file /tftpboot/actux1/u-boot.bin in 10.847293s (23.600 kb/s) This is definitely an AMD (02) commandset flash. (BTW: that write speed looks great - I was used to get around 12KB/s using my parport adapter) SST 39VF3201 works fine on my board, too, but I don't have a 39VF6401 to test. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
