USB2LT TashTalk Usb to LocalTalk

[twelvetone12]

I'm wondering if adding a buffer that selects R or D makes any difference, but I'm not sure, since the datasheet says R is high Z when RE/ is high, and D is ignored with DE low, so it really should make no difference. I'm confused.

 

[bigmessowires]

I haven't followed all the details of this, but could there be an output that's supposed to be open-drain and you're using push-pull outputs? That could cause problems in a two-transceiver setup where two sources could potentially drive the same signals.

 

[tashtari]

GOOD NEWS! I reproduced it with a two-transceiver setup! It's exactly the same, down to the 17 retries. I still don't know the root cause, but at least I can experiment for myself now.

I haven't followed all the details of this, but could there be an output that's supposed to be open-drain and you're using push-pull outputs? That could cause problems in a two-transceiver setup where two sources could potentially drive the same signals.

Shouldn't be... there aren't any open drain pins in the system. The TashTalk PIC has an active-high driver enable pin (always output) and a single pin that switches direction to do LocalTalk input and output; the transceivers have an active-high driver enable pin and an active-low receiver enable pin (both inputs), and the firmware changes direction on the LocalTalk I/O pin within one cycle (125 ns) of toggling the driver enable output pin.

 

[twelvetone12]

Super! I'm really curious if you find anything, I'm really out of ideas right now.

 

[tashtari]

I'm digging...

First off, it looks like 17 isn't as much of a clue as I'd hoped. There's apparently an old off-by-one bug in the firmware that means it tries sending a frame 33 times instead of the expected 32. Divide 33 by 2 and round up and you get... 17. Fixed that bug and now it retries 16 times.

Anyway, I think I have a root cause. Here's what's happening:

• TT sends its RTS frame
• Having finished, TT switches the LT pin into receive mode
• The LT pin (which is still cooling down from being driven) returns to idle (high), TT mistakenly thinks it's the beginning of a frame, and starts receiving it
• TT discovers that this non-frame is not the CTS frame that it's expecting, flags a collision, and starts to wait for the line to be idle so it can send another RTS frame
• The CTS frame comes in, TT starts receiving it, and echoes it to the UART
• TT isn't expecting a CTS frame because it's waiting for the line to be idle so it can send an RTS frame, so it flags a deferral and starts waiting for the line to be idle again

The double-fault of a collision followed by a deferral is why there are only 16 apparent attempts to send the frame.

Apparently, the two-transceiver arrangement has enough latency when returning to idle compared to the one-transceiver arrangement that it triggers the bug. This may be fixable by just inserting a delay, but I've got to be careful how and where I insert it... the TashTalk code is a bit delicate.

 

[twelvetone12]

If I understand correctly, the problem is that TT switches to input and then the pin goes high? What if we add a pullup?

 

[tashtari]

If I understand correctly, the problem is that TT switches to input and then the pin goes high? What if we add a pullup?

I'm not sure if that would work, I think the transceiver is correctly interpreting the state of the LocalTalk bus, it's just that the bus itself takes a few microseconds to return to idle and TashTalk isn't waiting long enough. I can correct this in firmware, I just need to make sure I'm doing it in a way that doesn't break anything else in the process.

 

[twelvetone12]

Mmmmh ok I see (and I tried the pullup and did not work lol), but maybe a transistor could do the trick? Basically it removes one of the two tranceivers from the bus when the LTEN pin flips?

 

[tashtari]

Mmmmh ok I see (and I tried the pullup and did not work lol), but maybe a transistor could do the trick? Basically it removes one of the two tranceivers from the bus when the LTEN pin flips?

You're welcome to try if you want to but I would think that the transceiver IC already does that - lowering the DE pin should stop it driving the LocalTalk bus at all.

Anyway, I think I know how I'm going to fix this, I should have a build for you to test within the hour.

 

[twelvetone12]

Cool! Thank you very much! I will try to test it this night if I make it or tomorrow morning. The scary part is that I need to desolder the PIC and I need to be fully awake for that

 

[tashtari]

Here it is! Let me know if it fixes things for you.

 

[twelvetone12]

Ok, I reprogrammed the pic and it works perfectly! I'm transferring files and printing. Thank you very much for this!
I want to run some more tests, like using a serial cable instead of the two phonenet adapters, but I think it is ok. Il will order new boards fixing the problems this one has, and if you want I can send you one.
Then we should see if the USB2PhoneNet thing is doable

 

[tashtari]

Ok, I reprogrammed the pic and it works perfectly!

Oh, thank goodness. =)

For future reference:



The trouble was caused by that little delay between when DE went low and when LT went high at the end of the RTS frame and before the CTS frame - I measured it at about 2.46 us in my setup. If you get a minute, could you measure how long the delay is on the USB2LT? The firmware now tolerates a delay of up to 5.5 us, I'd like to check that that's a comfortable margin before I release this fix as v2.1.1.

 

[twelvetone12]

If I got my reading right, it is around 1.8uS:



And here is the clean view:

 

[tashtari]

Okay, cool, thanks for checking that. 5.5 us seems like a good threshold. I'll update Github and release v2.1.1 shortly.

 

[twelvetone12]

Super! Thanks to you for looking into this. I fixed the other problems with the boards and I will order them this week.

 

[twelvetone12]

Finally had time to test the new boards, just to discover I made an error and the regulator releases the magic smoke. Who can spot the error? sigh



Time to make a next batch of boards I guess.

 

[tashtari]

Happens to the best of us. =/ My condolences.

 

[twelvetone12]

Well as they say, it's not use crying over spilled milk! So a new batch is on it's way, I just hope it arrives before I have travel again.

 

[demik]

Finally had time to test the new boards, just to discover I made an error and the regulator releases the magic smoke. Who can spot the error? sigh

Didn't use ERC ?