Hello. On Thu, 2011-05-12 at 05:54, Werner Almesberger wrote: > Stefan Schmidt wrote: > > Have you considered using the standard DFU method to signal a firmware > > upgrade during normal operation? > > I approached DFU from the other end: how can I replace a firmware > (application) that no longer cooperates ? That's how I came up with > running the DFU-capable boot loader for a few seconds before > jumping to the real application.
I did not consider the faulty app scenario. Good point. So it would be either a button for DFU mode or the waiting period. 2s waiting sounds like a good compromise to avoid the extra button. > The reset-to-DFU approach for bringing up DFU is only incidental: > since I already have the "unbrickable" boot loader with DFU, this > is merely a simple way for getting there. > > > I know you must have read the spec thats why I wonder why you wrote > > the tools to do these steps outside of DFU. > > I didn't write these tools specifically for getting into DFU mode. > atrf-reset's original purpose is to just reset whatever is there, > i.e., the transceiver and/or the MCU. usbwait is intended for > manufacturing use. It just happens to also help with the timing > issue in resetting into the boot loader. I guessed that you already had them handy for something else. :) > > Any problems you did run > > into? From a dfu-util point of view I want to support such setups and > > therefor would be interested if you did run into problems. > > I didn't run into any problems, I just never tried to use/implement > that mode. There may be more atrocities in my DFU implementation. I > just did whatever it takes for dfu-util to be happy with it. So > dfu-util is my de facto DFU standard :-) Could be dangerous. :) > If there's anything you think I really ought to fix, particularly in > the boot loader, please let me know. Three things come to my mind quickly. The usual problems I see in other implementations (haven't checked your bootloader code yet, will do when I have the hardware. :)). 1) Fill in the bwPollTimeout value with a sensible value (ยง6.1). The original u-boot and openpcd code did not do this and we had a fixed value in dfu-util. That did clash with system that provide the value and may get a better perfromance with these values instead of the hard coded one. We have quirks oin place for system with faulty value and it may not matter with your small payload size anyway. :) 2) Have a real USB from the USB forum assigned and be prepared to have a way to identify between different hardware revisions. 3) Add a dfu-suffix to your firmware file. See the spec annex. It contains the PID and VID it will work with (see my 2 comment) and a CRC over the firmware image. Dfu-util would then read the suffix and check if it makes sense to flash the firmware to the device (could be forced of course). This functionality is not there yet. I only have a hacked up prototype which parses the suffix. It could also make problems when dfu-util flashes the firmware _with_ suffix to the device as it does not detect it yet. As the last item is really only on the tooling side and not bound to the bootloader at all (suffix get stripped by dfu-util before flashing) this can wait. It actually has to wait until the dfu-util has gained support for it. :) > Ah, and now that you mention it ... there actually is a bug I ran > into ;-) Patch attached. Yay, great find. Applied and pushed. regards Stefan Schmidt _______________________________________________ Qi Hardware Discussion List Mail to list (members only): discussion@lists.en.qi-hardware.com Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
