[E3-hacking] PBL response

[Ralph Corderoy]

Hi Matt,

> Today I tried your 'exp' program with my setup.  How come it's so
> well-written in that it prints debug for EVERY termios option under
> the sun??  ;-))

Ah, well, when it didn't work ad nauseum, more debug got added to
double-check everything.

> (I mean, I had to comment half of them out to get it to compile on
> darwin ;)

Ah, good point.  I hadn't intended to ship the source.  Did all the
problems apper in print_termios()?  I suppose each use needs wrapping if
a #ifdef.  :-(

> Appended is its output;  from what I can tell it should be
> SENDING_ESCS, then get an ack, then send packets for opcodes 0 and 2 -
> these are "get version" or something?

That's about right.  Request 0x0000 should always result in a NACK reply
coming back.  Request 0x0002 prompts a reply containing version numbers
and maximum packet length.  If the request's checksum is messed up, or
something similar, then I think there should still be something coming
back.

> Anyway, having sorted out my serial woes (minicom) I've sent it a
> bunch of escs and seen the expected 006 006 006 006 006 006 006 006
> 006 006 006 006 006 006 006 response.  

Hurrah!  You're the first I know of to achieve that.

> Then I thought I'd try 'exp' and see what happens;  it moves to this 
> CS_HAVE_ACK state a bunch of times - I'm guessing because it gets 006 
> 16 times as the wakeup code print_strings a line of them.

Thanks.  You're right.  It moves to CS_HAVE_ACK on seeing an ACK
regardless of its current state.  I also see the stdout is a bit
corrupted when this happens.  You're executing un-trodden code paths
there!

> Then it just sits there doing nowt.  I'll take a closer look later on
> but just thought I'd let you know.  :)

It sends a couple of 0x0000 and 0x0002 requests in the hope that if it's
got it wrong, and is sending too few bytes for a request, the following
requests will provide the missing data, give a checksum error, and still
prompt a reply as opposed to the E2 just waiting a long time for more
data.

> (Other observation re WDT:  Quite a long timeout, you said 4-5 secs but 
> I observed about 15secs after having got the acks before the reboot.  

I think `wakeup' is written quite often to the WDT whilst it's waiting
for data.  There are other counters maintained by the code that decide
when to give up.

When the *E3* gives up after being paused due to EXP activity it doesn't
re-boot.  PBL re-scans memory, in case the protocol has changed
something, and continues to boot the next stage.  This is observable
because it prints stuff to EXP.

    Amstrad Delta - PBL V4.9 Build:1311 Assert Debug ICE
    PBL 32MB NAND
    0MB.-->MEMv01.00.002,CopyLim=00220000h,CodeEnd=01400000h-->PBL......1MB.......2MB*
    PBL 32MB NAND
    0MB.-->MEMv01.00.002,CopyLim=00220000h,CodeEnd=01400000h-->PBL......1MB.......2MB*

Normally, only the first three lines appear.

> Also, I see the WDT being initialised at 0x280.  WDTCTRL gets set to
> 0x67; this is WDT on, resetting, 2^29 clock ticks.

Agreed.

    0280  e3a080a5  mov r8, #&a5           # r8 = 0xa5, * = 0x27eb000f
    0284  e3a099fe  mov r9, #&3f8000       # r9 = 0x3f8000
    0288  e2499501  sub r9, r9, #&400000   # r9 = 0xffff8000 (WDTCTRL)
    028c  e2888ca5  add r8, r8, #&a500     # r8 = 0xa5a5, * = 0xffffffff
    0290  e5898004  str r8, [r9, #4]       # *0xffff8004 (WDTCNTR) = 0xa5a5 wakeup
    0294  e3a00067  mov r0, #&67           # r0 = 0x67, * = 0
    0298  e5c90000  strb r0, [r9, #0]      # *0xffff8000 (WDTCTRL) = 0x67 enable reset 2^29
    029c  e5898004  str r8, [r9, #4]       # *0xffff8004 (WDTCNTR) = 0xa5a5 wakeup
    02a0  eb001e7c  bl program_pio
    02a4  e5898004  str r8, [r9, #4]       # *0xffff8004 (WDTCNTR) = 0xa5a5 wakeup

> (This is about 1s at 50MHz

The DS_LH79531_B@E.pdf says on page 136:

    There are eight selectable time intervals for a timeout: 2^21, 2^22,
    2^23, 2^24, 2^25, 2^26, 2^29, or 2^31 clock cycles for time-out
    periods ranging from 41.94 ms to 41.95 seconds with a system clock
    of 60 MHz.

I can't turn 2^21 clock ticks at 60 MHz into 41.94 ms.  Similarly, 2^31
ticks isn't 41.95 seconds.  What am I doing wrong?

Do we know what speed the E2 ARM SoC is clocked at?

> my 15sec timeout must be a different timeout?)

Yes, I think things like 0x10034 come into play.  It gets set to 200 and
decrements whilst we're waiting.

    addr 00010028 req_09_received
    addr 0001002c req_09_baud_rate
    addr 00010030 num_bytes_rxd_on_last_check
    addr 00010034 protocol_fsm_counter # whilst waiting for rx.
    addr 0001003c rx_data_is_compressed # byte

> Also I haven't seen the FRZ (WDT freeze, lock-on) bit being set
> ever... is it set somewhere else?)

Not as far as I know.  This came up before with en4rab.

    http://www.earth.li/pipermail/e3-hacking/2005-February/000013.html

It may be worth skimming the list's archive,
http://www.earth.li/pipermail/e3-hacking.mbox/e3-hacking.mbox, perhaps
pull it into your email client or something, in case there's anything
else useful in there.

> 1110730112.095576 o 1b
> 1110730112.100625 o 1b

Can you readily reproduce the ACKs coming back from the ESCs with ./exp?
If so, I'd be interested to know how short the gap between ESCs needs to
be for it to work.  It's currently very short due to desperation.

> 1110730112.108426 i 061110730112.108435 e transitioning to state 2, 
> CS_HAVE_ACK

That should read

    1110730112.108426 i 06
    1110730112.108435 e transitioning to state 2, CS_HAVE_ACK

I'll try and fix it.

Thanks for the wonderful news.

Cheers,


Ralph.