[PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

[Tormod Volden]

On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt
<stefan at datenfreihafen.org> wrote:
> Hello.
>
> On Mon, 2011-12-19 at 00:07, Tormod Volden wrote:
>> From: Tormod Volden <debian.tormod at gmail.com>
>>
>> Also remove unused debug code.
>>
>> Signed-off-by: Tormod Volden <debian.tormod at gmail.com>
>
> Applied and pushed this one.

Thanks!

>
>> This patch, and two patches previously posted,
>>  main: List alternate interfaces in DFU mode
>>  main: Simplify --detach handling by reusing existing code
>> are also available on https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util/commits/master-patches
>
> I think we can both agree that I was to slow on these. :)

Yes, one problem is that I meanwhile forget what these patches are about :)

>
> I had another look and tested them. Sadly the simplify detch handling
> code works only from run to dfu and not from dfu to run mode. It was
> quite handy to have both transistions with the original approach.

"Detach" is to transition from run-time mode to DFU mode. There simply
is no "detach" from DFU mode to run-time mode. You want a command to
toggle between these two modes? Well, some devices can (from DFU mode)
reset themselves (and thus end up in run-time mode) in the
manifestation. However I am not sure a device can enter manifestation
state without doing some downloading. Please see the state diagram on
page 28 of the DFU 1.1 specification.

On what kind of device were you toggling back and forth between DFU to
run-time? It must be the result of some non-conformance or accidental
side effect.

>
> For the other patch I'm a bit unclear what benefit it brings over just
> doing the list mode in DFU. Having the full list when doing list in
> run time mode would be handy but involves a mode transition I'm not
> suere I'm happy to do without explicit user request.

You would like to do the list mode only in DFU mode? That would mean a
mode transition (assuming the device is in run-time mode), which I,
like you also express in your last phrase, would not be happy about. A
user probing the device using the -l option should not force any
device transition IMO. But I don't think we understand each other here
:) Let's talk about user cases, to make it clear what we want to do.

One example would be a device, that follows the DFU specification and
in run-time mode, lists one DFU interface with alternate setting zero.
The spec says it must be zero in run-time (Table 4.1). However, in DFU
mode it lists one DFU interface with several alternate settings, one
for each memory bank or something like that (Table 4.4).

The user will try to download a firmware image. He first runs dfu-util
-l and sees one DFU interface (with the single zero alternate
setting). So he does not specify -a. However, after detaching to DFU
mode, the device presents all alternate settings. Since dfu-util sees
several possibilities, and the user did not specify with -a, it will
with my patch, display the list of alternate settings and quit. Then
the user can rerun dfu-util, now with the -a setting of his choice.
The device is now already in DFU mode but that is not a problem, since
dfu-util detects the mode and skips the detach sequence. The selected
alternate setting is used and the correct memory bank/etc is
programmed.

>
> Doing a detach, a list of available alt interfaces and then a switch
> back to run-time might be doable but so far I was happy with having

This is not easily doable, and might even impossible as I explain
above, at least for standard DFU devices.

> these tasks in separate calls.
>
> regards
> Stefan Schmidt

Cheers,
Tormod