[PATCH 3/6] Cochran: Dump function no longer assumes reads begin at byte 0

[Jef Driesen]

On 2017-08-10 18:01, John Van Ostrand wrote:
> On Thu, Aug 10, 2017 at 10:57 AM, Jef Driesen <jef at libdivecomputer.org>
> wrote:
> 
>> On 2017-07-15 22:39, John Van Ostrand wrote:
>> 
>>> For previously supported Cochran computers high-speed read of
>>> log and profile data started at byte 0. Older models that lack the
>>> high-speed transfer function use the standard speed read commands
>>> and so the log and profile data are read at higher addresses.
>>> 
>> 
>> I don't really understand the reason for this change. With this change 
>> you
>> are only downloading the memory area containing the logbook and 
>> profile
>> ringbuffers, and not a full memory dump. Can you explain why you 
>> changed
>> this?
> 
> I figured I should start staging changes into patches that are more 
> easily
> reviewed and doing it in a way that still results in a good build in 
> case a
> build occurs at the commit. This patch is a staging patch intended to 
> set a
> path for support for Commander TM computers. This patch also fixes an
> assumption I made in _device_dump.
> 
> Prior to this patch the read command that read the log and profile data
> always had addresses that started at 0. Log data always started at 0 
> and
> profile data followed after. So layout->rb_logbook_begin for every 
> computer
> was always 0x0. In _device_dump I should have used this variable but I 
> used
> a hard coded 0. Using the variable makes more sense.
> 
> In effect, this patch doesn't change what the dump contains for 
> computers
> supported at the time of this patch. A dump done after this patch 
> matches a
> dump done prior to it.

I know the behavior remains the same for the existing devices. That's 
quite obvious when reading the code. But that's not what my question was 
about. It's about this part of your answer:

> As to downloading *all* memory I presumed it wasn't supposed to dump 
> all
> memory. I presume it was only supposed to dump log and profile data.
> 
> There may be two reasons why I thought the device_dump was only 
> intended to
> dump the user data, i.e. logbook and profile data. Prior to my patches
> currently under review, the code uses what I now realize is a 
> high-speed
> read function which seems intended to only download log and profile 
> data
> probably because of the large size. I was confused when working with 
> the
> older Commander TM models because the high-speed download commands 
> didn't
> work and I had no reference to how to download it (i.e. no vendor 
> program
> to observe.) Then I decided to brute force it recently, take the DC 
> apart,
> obtain the IC specs, and try a wide range of commands. I realized that 
> the
> read commands I've been using to access some data on new models were
> generic low-speed read commands and I could use them to access all 
> memory
> areas on the older computer. Because it had randomized SRAM logbook and
> profile data it took a while to find the user data. It starts at 
> 0x10000.
> 
> I could read all data on the old computer and dump all that data but 
> there
> are also 32K of RAM and ROM which I figure only confuses the data and
> doesn't help the user much. RAM, being RAM, changes a lot.
> 
> That said, I've started experimenting with a simulator that uses a full
> memory dump so there might be some benefit to changing this. The new
> simulator would be simplified and might be more robust when working 
> with a
> less predictable program like the vendor's software.

Memory dumps are not only useful for debugging today's problems. They 
can also help future development (developing new features, regression 
testing against old data, etc). But if you only download part of the 
memory, and it turns out the ringbuffer starts at some other address 
then your initial assumption, or your new feature needs some info from 
another area, then the old memory dump is suddenly useless. That's why a 
memory dump should (ideally) contain everything, and also require as 
little logic as possible (e.g. no knowledge of a certain address range).

A memory dump typically contains other sections besides the logbook and 
profile ringbuffer(s) too. For example:

  * Ringbuffer metadata (pointers where the next item should be written)
  * Configuration data (user configurable settings)
  * Dive computer state (decompression tissue loadings, etc)
  * ... (lots of things we don't know about)

There is probably lots of stuff we aren't interested in, but that's 
difficult to tell in advance if you don't even know what's in there. So 
making sure to include everything is the most future proof :-)


Having said that, if the download protocol uses addresses where certain 
ranges are mapped to the ROM (firmware code) or even RAM, then that's 
indeed another story. We're not really interested in that kind of stuff. 
Just the flash (or some other non-volatile storage technology) where the 
dives are being stored. But so far I've never seen any dive computer 
where the download protocol gives access to that kind of data (except 
for the ostc firmware updater).


Have you checked (on the newer devices), whether a read operation at the 
same address with the slow and fast commands, yields the same data?

Jef