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
