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.