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
