Peter C. Wallace wrote:
> On Thu, 4 Dec 2008, Eric H. Johnson wrote:
>>
>> I am getting a strange error using the hostmot2 driver and the 7i43 board.
>> The error is "hm2/hm2_7i43.0: TRAM write error! (addr=0x1000, size=8,
>> iter=68373). The error occurs when running a g-code program but not while
>> jogging, at least initially.
>
> Sebastian: what causes a TRAM write error?
First I want to clarify that the hostmot2 driver does not actually use
the Translation RAM yet. The error is from the placeholder code that
some day *will* write to the TRAM. Currently the driver keeps track of
how it would *like* the TRAM set up, but it does all the I/O "by hand",
meaning with a separate EPP Address-Write cycle (actually two) for each
contiguous register region.
The error Eric is seeing is emitted when the hm2_7i43 driver detects an
EPP timeout after a "wannabe-TRAM" write. It writes the 16-bit address
(0x1000 in the case above), writes 8 bytes of data, then checks the EPP
Status register and finds bit 0 is set.
Eric reports not being able to jog after the error happens. This is at
least partially because the hostmot2 driver deliberately stops talking
to the board after an EPP timeout. It sets the hm2_7i43.io-error HAL
pin to True, and while this pin is True the driver refuses to do any I/O
with the board. The user can set the pin back to False to force the
driver to start talking to the board again.
Note that the io-error condition will almost certainly trigger a
watchdog bite, so the hm2_7i43.0.watchdog.has-bit pin will need to be
set back to False. This needs to happen *after* the .io-error pin has
been set to False.
> I dont know if it would be caught by software checking but ISTR the 7I43
> cannot use a base thread (EPP operations need to be atomic) so a 7I43 HAL
> should only normally only use a Servo thread
I saw Eric's later reply saying he's using one thread only, but FWIW the
hostmot2 driver tries to protect against this. hostmot2 knows that the
7i43 cannot tolerate being accessed from multiple threads, so it does
not export the GPIO-only access functions. It only exports .read() and
.write(), which do GPIO and everything else. Those two functions may
only be called from a single thread, but I think that's a fairly
ubiquitous way of doing things.
The PCI-based AnyIO boards export .read() and .write() (which read and
write all the stuff on the board), plus .read_gpio() and .write_gpio()
(which read and write the GPIOs only, in case the user wants to do that
more frequently).
--
Sebastian Kuzminsky
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
