Thanks. I think David and I have both been improving the error handling in places that we touch, but we need a more systematic approach to it. I have been thinking about starting an automated test suite for 0.4.0, as such might have prevented a few of the minor issues that we've seen. Any contributions that you feel like making... send the patches. :)
On Thu, 2009-11-19 at 17:15 -0600, Dean Glazeski wrote: > Here's a patch to fix the increment. I'll mess around with error > output later. There are a lot of areas that I would like to visit to > update error output. So many errors don't present proper fault > output. It makes it hard to trace problems when regressions happen :) > I'll spend some time with that once I have the AT91SAM9 NAND working > and get a start with the dataflash. > > // Dean Glazeski > > > On Thu, Nov 19, 2009 at 5:12 PM, Zach Welch <[email protected]> > wrote: > On Thu, 2009-11-19 at 15:08 -0800, Zach Welch wrote: > > At the moment, I just want correctness. Thanks for doing > the detective > > work, but you're also welcom. > > > Whoops... that one slipped away from me.... you're also > welcome to put > together an initial patch for it. Similarly, you are welcome > to submit > a patch to improve the output, but I think the memcmps are > good for the > first check. A for-loop (in a static helper function) could > then do a > slower check to produce good output. > > -- > > > > On Thu, 2009-11-19 at 17:04 -0600, Dean Glazeski wrote: > > > After writing this email, I came across the bug. There > are a few ways > > > to fix it and I'll leave it to you to decide. The > dev.address needs > > > to be advanced with the file.address in the main verify > loop. This > > > might be replaceable by just advancing dev and not file, > or moving > > > both, etc. > > > > > > As another note, would it be better to have a for loop > iterate through > > > data as opposed to using memcmp? memcmp is faster, but > you can > > > provide more information if things are in a for loop. > > > > > > // Dean Glazeski > > > > > > > > > On Thu, Nov 19, 2009 at 4:58 PM, Dean Glazeski > <[email protected]> > > > wrote: > > > nand verify is not working. I'm trying to trace > it to the > > > problem, but it appears there is something wrong > with the file > > > struct that's reading the file. Somehow the data > read from > > > the file doesn't match the actual data in the > file. The odd > > > ball thing is that nand erase, followed by nand > write, > > > followed by nand dump produces matching bin files > to the > > > original written bin file. It also appears that > the file > > > struct is used in the same way in the nand write > handler, so > > > I'm a bit confused. I'm going to keep poking > until I figure > > > it out or some one posts something here. > > > > > > As another curveball, it reads 0x1B when not > verifying oob and > > > 0x05 when I tell it to at location 0. The correct > value in > > > the file is 0x1E for that location and the NAND > device does > > > return this value when read. > > > > > > // Dean Glazeski > > > > > > > > > > > > > > > On Thu, Nov 19, 2009 at 9:15 AM, Zach Welch > > > <[email protected]> wrote: > > > On Wed, 2009-11-18 at 23:25 -0600, Dean > Glazeski > > > wrote: > > > > Hi all, > > > > > > > > Recent NAND file I/O changes are parsing > the wrong > > > argument for the > > > > size. Should be third argument, not > second. > > > > > > > > > Pushed. Let me know if you find any other > problems. > > > Incidentally, does > > > the 'new verify' command work for you > (after this > > > fix)? :) > > > > > > --Z > > > > > > > > > > > > > > > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
