[E3-hacking] PBL response
Ralph Corderoy
e3-hacking@earth.li
Sun, 13 Mar 2005 17:28:08 +0000
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.