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.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
USB2LT TashTalk Usb to LocalTalk
- Thread starter twelvetone12
- Start date
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.
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.
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.
Super! I'm really curious if you find anything, I'm really out of ideas right now.
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:
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.
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
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.
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.
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.
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 
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
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
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.
If I got my reading right, it is around 1.8uS:
And here is the clean view:
And here is the clean view:
Super! Thanks to you for looking into this. I fixed the other problems with the boards and I will order them this week.
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.
Time to make a next batch of boards I guess.
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.
Similar threads
