Silvercrest SL-65
Data retrieval experimentations

Disclaimer

Why?

Ewen found for me the proper Silvercrest website which had tools for the Silvercrest version of the SL-65. Thanks Ewen!

Great! AliEditor connected to my receiver, so I could now back up the firmware, and be able to look at the channel listings.
It was a good idea, and might have worked had the dopey software not decided upon creating a zero-length dump. Lovely!

Where do we go from here?

How it works

The available commands (looking in the firmware dump) appear to be:

• address
• b
• burn
• c
• comtest
• dump
• move
• reboot
• transfer
• transferraw
• version

The transcript

Data read from the receiver is marked in light blue.
Data written to the receiver is marked in light read.
It appears that the receiver may echo some stuff.
 
The leftmost column describes the operation.
The next column shows the data in a cooked ASCII form.
The right column shows the data in hex, with 0x prefix so you know.

Analysing the transcript

Therefore...

It appears that we begin the process by outputting:
   comtest [0D]c[0D]
to a serial port running at 115,200bps with the protocol of 8 data bits, 1 stop bit, even parity - usually abbreviated to "115200 8E1". Note - 8E1, not 8N1.
Just in case clarification is required - the values in square brackets that are italicised (for example "[0D]") are hex bytes.

The receiver would appear to echo the "comtest" but not the final four bytes.
The receiver will reply with:
   APP init ok[0D][0A]
 
We then output:
   c[0D]c[0A][0D]
Note that the CRLF sequence is reversed.
The receiver then replies with:
   >:[[0A][0D]>:c[0A][0D]>:
Again, note that the CRLF sequences are reversed.
 
At this point, the front panel LEDs will say "ASH ". This is only visible when using my software as I have longer time-outs than AliEditor.
 
We now send the command:
   comtest 10[0D]ali DVB-S
to which the receiver replies with a command-line of sorts:
   [0A]>:
 
At this point, the front panel LEDs will say "conn".
 
We send the command:
   dump[0D]
The receiver replies with four bytes:
   [00][20][00][00]
In little-endian (Motorola/ARM) byte ordering, this equates to "1<<16" which is 2,097,152 - or two megabytes. This is probably the size of the dump that is to be returned.
 
At this point, the front panel LEDs will say "dup ", but you don't normally see this when using AliEditor.
 
We then output:
   O
(upper case 'o', perhaps for "ok"?)
 
The receiver will then reply with loads of data. A complete dump of the 2Mb FlashROM.
 
It appears that there is no official 'finish' to the transfer, and currently if you don't catch all the data in time, stuff gets missed.
 
I have my suspicions that AliEditor may be abandoning the transfer due to the speed of the serial link. Let's put it like this - I regularly transfer files to/from my RiscPC at 115,200bps using HyperTerm and HearSay2. Sending to the 40MHz ARM is no trouble whatsoever - the RiscPC can more than keep up.
Returning data (from the 40MHz RiscPC) to the 466MHz Celeron PC results in numerous retries and communications errors. It will work, as Zmodem is robust, but it appears the PC frequently loses bytes.
Now, I know you cannot compare clock speeds of a RISC and a CISC processor, and I know one is running a hand-crafted assembler operating system and the other Windows... but whichever way you slice the cake, the brute speed of the PC is eleven times faster, not to mention a memory subsystem probably clocking around 66MHz (instead of the RiscPC's 12MHz bottleneck).
Anyway, the point isn't to slag off the x86's interrupt latency or Windows serial port handling, the point is to try to come up with reasons why AliEditor is not working for me - as surely if it simply does not work, somebody at Silvercrest might have noticed by now!

Putting this in action

Spot the wally!

Modifications to bring the code to v0.03

Here are the changes required to update v0.02:

• Lines 15 to 18
  Erase the four lines beginning "It makes a 16-bit DOS program", as these comments were more relevant to PSMD from which the original serial code was taken.
  Not doing this will affect the following line references.
  You'll probably want to update the version number in line 1, and the date in line 3... '0.03' and '2007/04/01' respectively.
   
  
• Lines 47 & 48
  Update the version number and date.
  Change to:
     char appvers[] = "0.03";
   char appdate[] = "2007/04/01";
   
  
• Line 488
  We had set the FIFO to trigger an interrupt after 14 bytes (the FIFO holds 16). Now we request an interrupt after 8 bytes - so it can receive a further 8 bytes while we are handling the interrupt request.
  Change to:
     outp((port + 2), 129); /* FIFO trigger after 8 bytes; give us room */
   
  
• Line 589
  Another left-over from PSMD...
  Erase the three lines to do with closing the log file, and the following blank line to close up the gap...
   
  
• Line 612
  Disable RTS during serial read.
  Change:
     int lsr = 0;
  To:
     int lsr = 0;
 
   /* Turn off RTS during read - we are NOT ready */
   outp((port + 4), 9); /* nDTR and OUT2 */
   
  
• Line 625:
  Enable RTS after read.
  Change:
     outp(0x20, 0x20); /* Flag IRQ handled */
  To:
     outp(0x20, 0x20); /* Flag IRQ handled */
 
   /* Turn on RTS again */
   outp((port + 4), 11); /* nDTR, nRTS, and OUT2 - we can go again */

Serial port setup could be improved by disabling interrupts around the setup code (using disable(); and enable();). As it happens, this makes little difference, and I am not happy about disabling interrupts unless it is absolutely critical.

FINALLY - go to the compiler options and ensure that the choice for "Register variables" is off. I had, previously, set it to automatic. It appears that the compiler may generate bogus interrupt handling code if this option is incorrectly set.
It seems to make little difference in practice, however the built-in help explicitly states: When you use the interrupt keyword, the Stack warning checkbox should be unchecked (off) and the Register Variables option should be set to None.