Hello Ralph,
Thanks for your updated exp! I've just tried it out:
1110839334.812694 o 1b 1110839334.817746 o 1b 1110839334.822813 o 1b 1110839334.824815 i 06 1110839334.825299 e received ack 1110839334.825719 e transitioning to state 1, CS_STOPPED_TX_ESC 1110839334.826307 o 02 00 00 02 00 00 02 02 00 00 02 00 02 04 1110839334.826756 i 06 1110839334.827292 i 06 1110839334.827960 i 06 1110839334.828841 i 06 1110839334.829829 i 06 1110839334.831813 i 06 1110839334.832834 i 06 1110839334.833835 i 06 1110839334.834831 i 06 1110839334.835828 i 06 1110839334.836829 i 06 1110839334.837831 i 06 1110839334.838829 i 06 1110839334.839828 i 06
So it sends the packet... but nothing back.
However it hasn't finished receiving the acks and the E2 is busy-waiting on the TX queue at this point (it's not the interrupt-driven "print string" routine IIRC, it's just a spinloop) so I altered exp to count the acks and move on only when it sees 16 of them: (which incidentally it didn't always get, sometimes 15.. loss..)
1110839701.916260 o 1b 1110839701.921314 o 1b 1110839701.926360 o 1b 1110839701.931406 o 1b 1110839701.949244 o 1b 1110839701.950278 i 06(14 acks left) 06(13 acks left) 06(12 acks left) 06(11 acks left) 06(10 acks left) 06(9 acks left) 06(8 acks left) 06(7 acks left) 06(6 acks left) 06(5 acks left) 06(4 acks left) 06(3 acks left) 1110839701.951045 i 06(2 acks left) 1110839701.951959 i 06(1 acks left) 1110839701.952959 i 06(0 acks left) 1110839701.953517 e transitioning to state 2, CS_HAVE_ACK 1110839705.954042 e transitioning to state 1, CS_TX_REQUEST_ONESHOT 1110839705.955233 o 02 00 00 02 00 00 02 02 00 00 02 00 00 02 02 00 00 02 00 00 02 02 00 00 02 00 02 04 02 00 00 02 00 02 04 02 00 00 02 00 02 04
.... Nada.
'Voice' and 'email' LEDs at top alternate rapidly (with every ESC received? Certainly boots much slower, it watches ESCs for a while then replies the 06s. After receives the 2nd transmission it sits in a loop alternating the LEDs at about 2Hz.
***** Scratch that - I've bodged your code wrongly. <quick re-bodge>
RIGHT! It replied! I pruned out the "send the NOP packet 3 times then the INFO packet(2) 3 times" stuff down to only sending one packet. Also your description of the protocol quite accurately says the opcode is the first byte in the payload whereas exp.c had it reversed (i.e. 02 00 not 00 02) - also I found the length field was also being sent reversed. See below; I altered the endianness of the length field, and also that of the opcode field so that the LSB was sent first. I got an acknowlegement!!
... 1110841583.893639 i 06(3 acks left) 1110841583.894640 i 06(2 acks left) 1110841583.895639 i 06(1 acks left) 1110841583.896637 i 06(0 acks left) 1110841583.897060 e transitioning to state 2, CS_HAVE_ACK 1110841587.897492 e transitioning to state 1, CS_TX_REQUEST_ONESHOT 1110841587.898645 o 02 00 02 00 02 00 04 1110841587.907837 i 02 1110841587.908858 i 00 1110841587.909852 i 0e 1110841587.910849 i 00 1110841587.911845 i 82 1110841587.912846 i 00 1110841587.913844 i 72 1110841587.914842 i 00 1110841587.915845 i 03 1110841587.916845 i 01 1110841587.917846 i fd 1110841587.918844 i 04 1110841587.919843 i 10 1110841587.921825 i 20 1110841587.922844 i fe 1110841587.923844 i 7b 1110841587.924842 i 0e 1110841587.925844 i b0 1110841587.926844 i 6e ^C1110841635.489371 e received signal 2, exiting.
:D
I was just getting ready to give up (or at least see which loop it was spinning in via JTAG).. I'm pretty damn impressed, I have to say, with the accuracy of your reverse-engineering for the reply! (Especially because I hit the disassembly again tonight trying to work out if there was something else necessary before it'd listen - and got nowhere.)
So: 02 00 0e 00 [ 82 00 72 00 03 01 fd 04 10 20 fe 7b 0e b0 ] 63
03 01: Matches, I've v3.1 fd 04: as you predicted, of course, 1277 ... etc. as per your packet format spec.
Some notes:
o Once it's in this idle state it still flashes leds at 2Hz as above.. a healthy sign I think? o Duff packets are NOT acknowleged o I tried hacking exp to just send a ton of escape chars without a timeout - this didn't result in a reply! So the gap between them is good. It seems to watch for a number of these - (I see 20 being bandied about around 0x324 in the code) and any number pauses boot for a bit. Stated differently, it boots quicker if you don't send anything, whereas sending ESCs delay it for a bit even if it doesn't reply with 06060606.. for a few seconds.
Time to call it a night. But looks like there's potential for a play with some of the other commands of the protocol! (First step = get some code into DRAM..) Looks like all your hard work has been pretty much spot on, so congratulations :) Have you managed to recreate getting the stream of ACKs back with your setup? I should find a source of cheap MobilePhone data cables somewhere, for ease of modding into E2 EXP cables.
Best regards,
Matt