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? > 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. >> Q3: Does this "command set" difference mean that I am in the same 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 But they do refer to "CFI" flashes... Does this help in understanding my problem? Regards Flemming -----Original Message----- From: Michael Schwingen [mailto:rincew...@discworld.dascon.de] Sent: 30. december 2009 13:47 To: Flemming Futtrup; openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B external flash Flemming Futtrup wrote: > Info : Flash Manufacturer/Device: 0x00bf 0x236d > > Error: Could not probe bank: no QRY > > Try workaround w/0x555 instead of 0x55 to get QRY. > > Error: Could not probe bank: no QRY > > Error: auto_probe failed -900 > > > > At this point I assumed that the concerned Flash device is a NON_CFI device. > It seems so, although the datasheet talk about CFI support. However, the datasheet talks about a three-byte command to enter CFI mode, which is in conflict with the CFI spec. I remember some older SST flashs had the same problem (and when using the 3-byte sequence, the CFI tables were present, but broken). If the 39VF6401B behaves like that, it is probably best to treat it as a non-CFI device. > All this does not help me very much as I cannot flash anything to this flash, here are my observations: > 1. I can get a flash info and then all blocks are in a "protection state unknown" condition. This can be solved by applying a "flash protect_check 1". Then a "flash info 1" says that every block is protected. > 2. I can disable the "working area" and then it seems to flash but very slowly and pretty useless with an 8M flash. This leads me into thinking that chipselect and all these things are OK.? > It also means that the command set and programming algorithm work fine. Without the workspace, the whole programming algorithm runs on the host, using seperate word accesses to the flash. > 3. The flash I am using is identified to have "CFI Query string" where " Primary OEM command set = 0002H @ address 13H" Whereas my Embedde Aritist board flash that works nicely has a "command set = 01H". > 01 is Intel/Sharp, 02 is AMD/Fujitsu. The commands in the datasheet seem to match the AMD command set, so using that seems fine. Since other AMD-style flashs work fine, this is probably not the problem. > My OpenOCD 0.3.1 is simply throwing this kind of message after me : > > > > non-cfi flash: > > mfr: 0x00bf, id:0x236d > > Error: timed out while waiting for target halted > Error: error writing to flash at address 0x80000000 at offset 0x00000000 (-902) > 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. > Here are some more observations, which might be relevant: > > The SST39VF6401B and SST39VF6401 are not the same e.g. Primary OEM command set are 01H vs 02H > 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)? 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 SST39VFXX01 and SSTVFXX02 differs in working with Top vs Bottom boot blocks, whatever that means... > That is only the sector layout - bootblock flashs have some sectors that are smaller than the majority of sectors, for storing bootcode, and these may be at the beginning or at the end of the flash - which variant you need depends on where your CPU fetches its reset vector. > Q1: Does any of the things I did make sence (someone suggested that the device really is a CFI Flash and my effort is a waste of time - how can I know)? > After a close look at the datasheet, I think you did the right thing - SST claims the flash to be CFI compliant, but the datasheet tells that it is not. > Q3: Does this "command set" difference mean that I am in the same 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? cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
