Piconet refresher course

[jubber]

I have Ken Lowe's piconet adaptor, connected to an econet which I know is working (tested on an A5000) but after many months of not using it I've forgotten how to connect. The piconet thread is 88 pages long so a bit tough to wade through.

I've connected to the piconet without holding down the little grey button, so it's not in USB mode. In powershell on Windows I've typed ecoclient status and get the following -
Ecoclient version 2.0.17
device name [auto]
station no - 77
server - 254
debug - false
board connected - true
firmware version - 2.0.20
adlc status reg. 1: 11111111

that seems fairly promising although peraps firmware and ecoclient should match. However typing ecoclient i-am syst gives the message
"Failed to send command to station 254: UNDERRUN"

UNDERRUN comes back from anything I try, such as ecoclient cat

I bet there's some simple step I've forgotten in this process. Can anybody help? Oh, and sorry if this is the wrong forum.

[IanJeffray]

adlc status reg. 1: 11111111

Hmm. That looks odd. I see ADLC status reg. 1 : 00000100
Did you connect Econet before USB? I find if I do it the other way around, I usually get line-jammed / no_data_ack / no_scout_ack errors

The Piconet thread is only 6 pages btw - I think you may have been looking at the Pi Bridge thread?

[jubber]

Oops - wrong thread, you're absolutely right.

My econet is permanently on, so the piconet is always connecting to something that is already active.

[jubber]

Fixed.

If anybody else has this odd behaviour -

Hold down the little grey button when connecting to the USB and you'll see the device as a hard drive. Drop piconet.uf2 into there (available from https://github.com/jprayner/piconet/releases) and the USB drive will disappear as the piconet reboots.

ecoclient status now shows 01000000
ecoclient cat gives a different error - success but not enough data.
ecoclient i-am syst followed by ecoclient status and ecoclient cat and suddenly there's a working econet directory dump in powershell.

Terrific! Thanks Ian - the link to the right thread was enough to get me back on track.

[jubber]

One other thing that I did last night that may be necessary as part of fixing the issue -

npm install -g @jprayner/ecoclient

It might be necessary for both software on the PC side and piconet side to be updated.

[IanJeffray]

Drop piconet.uf2 into there

Odd. You already had the latest firmware and client (or, at least, the same versions as I'm using).

[jubber]

Yeah - I'm not sure why any of this was necessary - I've not touched the piconet in a couple of months, and it was working back then.

[JimR]

Glad to hear you're up-and-running, jubber!

Did you connect Econet before USB? I find if I do it the other way around, I usually get line-jammed / no_data_ack / no_scout_ack errors

Whoa, that's weird. Can you reproduce this reliably? I don't seem to be able to. Right now I'm testing against a PiEconetBridge but will try against my L3 fileserver and SJ Research clock tomorrow.

ecoclient cat gives a different error - success but not enough data.

Ahem, yes, I was aware of that one. I'm not handling the error response correctly from the server if you're not logged in when you execute CAT. I've raised an issue so I don't forget to fix this bug: https://github.com/jprayner/piconet/issues/4

[arg]

I wonder if you were suffering from back-powering of the interface from the Econet side?

I've certainly encountered this on other RP2040 projects where power leaking in from the data pins on some connected interface gives sufficient power to stop the RP2040 getting a clean power-on reset. This doesn't sound quite like that (the RP2040 was clearly booted and talking to you, but the ADLC looked like it had failed to reset properly). Maybe there's enough power leakage from the Econet to fully boot the RP2040 - but the 6854 would not be sufficiently powered when it got initialised under those conditions?

[JimR]

I wonder if you were suffering from back-powering of the interface from the Econet side?

I've certainly encountered this on other RP2040 projects where power leaking in from the data pins on some connected interface gives sufficient power to stop the RP2040 getting a clean power-on reset. This doesn't sound quite like that (the RP2040 was clearly booted and talking to you, but the ADLC looked like it had failed to reset properly). Maybe there's enough power leakage from the Econet to fully boot the RP2040 - but the 6854 would not be sufficiently powered when it got initialised under those conditions?

That last scenario sounds interesting. Currently I assert !RST on the 6854 when the RP2040 boots. For this application it wouldn't hurt to reset the 6854 each time ecoclient runs which could help. First I need to find a way to reproduce the problem, otherwise I won't know when I've solved it!

[IanJeffray]

First I need to find a way to reproduce the problem, otherwise I won't know when I've solved it!

If it helps, I can readily reproduce my problems here. Below is a log of a typical session with PicoNet...

Code: Select all

G:\>ecoclient status
Ecoclient version  : 2.0.17
Device name        : [auto]
Local station no.  : 1
Server station no. : 254
Debug enabled      : false
Board connected    : true
Firmware version   : 2.0.20
ADLC status reg. 1 : 00000100

G:\>ecoclient i-am syst
Failed to send command to station 254: NO_SCOUT_ACK

G:\>ecoclient i-am syst
Failed to send command to station 254: NO_SCOUT_ACK

G:\>ecoclient i-am syst
Failed to send command to station 254: NO_DATA_ACK

G:\>ecoclient i-am syst
Command failed:

G:\>ecoclient i-am syst

G:\>ecoclient cat
[$ (16) - Owner]
!PartMgr   00000000 00000000      4096 DWR/       27/09/23 03F5A3
(etc...)

Once it's "warmed up" and has done a successful log on, it's fine thereafter.