On Fri, 14 Oct 2011 23:15:09 +0100 Iain Paton selsinork@gmail.com wrote:
Stefan Tauner wrote:
AT49BV002A(N)'s ID is 0x07 afaics and that's equal to AT49F002(N)... hm.
tried 7 & 8, 8 for the T version according to the datasheet, but nothing to lose trying both
does the log show any other result than 0xff/0x00 (for any chip, if you probe for all of them)? i think you have not posted a log for that one, have you?
what did you try? does probing with the nicintel_spi code help?
didn't appear to, but I'm assuming that when you did it you left it stuck in the loop while you tried the nicintel code ? Carl-Daniel's patch means it doesn't get stuck anymore, so I need to either revert that or try something else.
no, i aborted after entering the loop. the enable method is executed at startup of the programmer... hm. maybe it gets reversed since then. carldani added some kind of roll-back mechanism where the code registers certain actions in init functions etc. that are reversed on shutdown. but i think ctrl+c just aborts anyway... after looking at the code... the comments in nicintel_spic.c explain that the roll-back thingy is not possible, but it does it manually in the shutdown function, but i am quite sure that this is not called at all when you abort while probing... so it should be ok. *shrug*
so it is certainly not exactly the same problem i had; and i cant help you further right now, sorry.
np, with these being pci cards their usefulness is limited to me nowadays, in fact I think they've sat in a box since last time :) so it's mostly curiosity on my part, no burning need for me to solve it.
that was my motivation too... and that's not a very strong one ;)