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

[John Van Ostrand]

On Fri, Aug 11, 2017 at 10:33 AM, Jef Driesen <jef at libdivecomputer.org>
wrote:

> 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 :-)
>

The ID, conf, and misc blocks should give us everything we want. ID tells
us the model and f/w version (I think), conf pages give us the configurable
settings and I think misc gives us tissue loading. The original code was
dumping all this. I'm not sure why it was removed.

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).
>
>
I disassembled the Commander TM to identify the MCU. In the downloads I can
see memory structures that match what the specs suggest should be there,
the interrupt table is visible at the beginning of ROM. I've done captures
minutes apart and compared the results. The parts that change correspond
strongly to the RAM, LCD RAM, and internal IO registers outlined in the MCU
spec, things expected to be dynamic. So I'm pretty sure we're looking at
the entire 32K address space of the MCU. I've not gathered the courage to
disassemble my expensive Cochran computers (or borrowed ones) so I'm
guessing a little more with those.

There are two write commands that I'm aware of. One appears to be able to
address all mapped space. It's how the time is changed. The format is:

  0xa0 0xXX 0xYY 0xZZ 0xVV 0xWW (write 0xWWVV bytes (following command) to
address 0xZZYYXX)

Like the slow read command this one is supported across all DCs I've tested.


> 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?


I have. Slow reads seem to read the MCU addressing space. The EMC-20H looks
very similar to the TM (same MCU?) The Commander II appears slightly
different (different MCU?) but it also appears to be the full address space.

-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20170811/2a458405/attachment-0001.html>