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

[Stefan Schmidt]

Hello.

On Mon, 2011-12-19 at 23:38, Tormod Volden wrote:
> On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt
> <stefan at datenfreihafen.org> wrote:
> >
> >> 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 :)

:)

Lets see that we get it sorted out then. :)

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

You hit the nail here. :)

I tested it with with the U-Boot implementation and other devices that
seem to implement the reset in DFU mode. Not really was thinking about
the spec here that does not specify this. My bad. :)

I'm checking with a bluetooth dongle now and will apply your patch
then. Thanks for taking the time and patience to explain this.

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

OK. We agree that we don't want any mode transition without explicit
user request. The rest is real misunderstanding, indeed. :)

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

Correct. The usual behaviour.

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

Ah, ok. It lists the alternate settings only in DFU mode when now
argument is given for -a. Makes sense. Will test and apply.

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

Agreed. I just tested it and it worked with some
devices/implementations but it slipped my mind that it is not
guaranteed/designed by the spec. Thus your solution makes more sense
here.

regards
Stefan Schmidt