• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

USB2LT TashTalk Usb to LocalTalk

twelvetone12

Well-known member
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

Well-known member
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

PIC Whisperer
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.
 

tashtari

PIC Whisperer
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

Well-known member
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

PIC Whisperer
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

Well-known member
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

PIC Whisperer
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

Well-known member
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

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

Attachments

  • tashtalk-2.1.1-rc.HEX.zip
    4.9 KB · Views: 1

twelvetone12

Well-known member
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

PIC Whisperer
Ok, I reprogrammed the pic and it works perfectly!
Oh, thank goodness. =)

For future reference:

troublespot.png

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.
 

tashtari

PIC Whisperer
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

Well-known member
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

Screenshot 2024-01-19 alle 15.00.21.png


Time to make a next batch of boards I guess.
 

twelvetone12

Well-known member
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.
 
Top