Yes this is the same machine...same CMOS (bios) settings.
I am running an Athalon 1200 (not exceptionally fast). But to make
things interesting I am running this with Gentoo linux (custom built for
the machine).
It works for most things quite well.
It is acting like a timing problem... I really need to get a logic
analyzer to determine what is going on. It is a little hard to tell
without seeing where the differences are.
Under 98.. both IAR and GNU tools seem to work. Under linux it is a bit
flaky ... I am thinking of porting to a Mandrake machine that is around
to validate the it works well. These are only 1GHz machines.
I have compiled the ppdev and parport into the kernel (not modules) with
no real effect. that is ... still flakey.
I have not tried to take it any further. I may need to sort out a logic
analyzer and how to get the HIL lib into debugging mode. That will be
another day i am sure.
Regards,
Jim
On Sun, 2003-08-17 at 20:02, Steve Underwood wrote:
> Hi Jim,
>
> jim wrote:
>
> >I'm still assuming this is local to my installation
> >
> >I removed IEEE 1284 support from my kernel and left ppdev and parport_pc
> >as loadable modules. Now the gdbproxy finds the unit straight away.
> >One issue removed.
> >
> The Linux machines I have used all run RedHat (various versions), and
> have no attached printers. This will mean they do not have the normal
> printer modules loaded. I have never tested whether these might
> interfere with ppdev. It sounds like they might do.
>
> >I still get an error when I try to erase flash ("Could not
> >preserve/restore device memory (12)").
> >
> >When writing to memory (load test1) I get several "could not read
> >device memory (6)" errors for reads of locations 0xffff, 0xfffe, 0xffe0.
> >
> These sound like a genuine failure to communicate with the target. I
> have had no trouble that wasn't genuine hardware related trouble. If you
> are seeing the initial message where the software identifies the
> attached device, then obviously communication can occur. It sounds like
> you just have flaky communication, and that sounds hardware related. I
> don't mean faulty hardware (although that is a possibility). I mean
> hardware where the timing goes wrong. The FAQ lists some things people
> seem to have had trouble with in this area.
>
> >I did install this under win98.... it seems to work just fine there.
> >
> Hooray! Someone says it works OK under Win98. There were problems with
> Win98 a few months back. I have had zero feedback as to how well things
> work now I fixed the key problem.
>
> >It seems the IEEE 1284 support causes issues. I have not tried
> >compiling in the parport_pc and ppdev. these are loadable modules at
> >this point.
> >
> Loadable modules are generally a good thing in modern Linux kernels.
>
> >Does anyone have any ideas what would causing this problem?
> >
> >
> No. Not really. What Linux are you using. As I said, all testing was
> done with RedHat 7.2, 8.0 and 9.0 and I never had any problems of this
> type. The FAQ lists some hardware related issues (and workarounds)
> people have fed back to me. What Linux are you using? Is Win98 working
> on the same machine?
>
> I'm really interested in resolving problems like this, as I'd like to
> ensure these tools work more smoothly across a broad range of the latest
> hardware. It does, however, seem that people are having more trouble
> with the latest fast machines with mspgcc, and other MSP430 toolchains.
>
> Regards,
> Steve
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
