DFU bootloader

[OldNick]

Hi,

Have just been trawling through the DFU bootloader appnote. AN4370

Puzzled why we have to have code for a "mouse" included in the build

Any ideas?

[bob_walker]

Has anyone gotten AN4370 to work with the HCS08 - JM60, for example?

[PaoloRenzo]

Hi, what's the problem you're seeing?

App Note SW was updated and some lines changed for performance

Hope this helps

[KC_ARM]

Hi Paolo, is it possible to get the source code on the PC side for the DFU sample that you've  created? I need to port that to a different platform other than MS Window.

Thanks.

[Dekiru]

In a system with bootloader, the bootloader is activated (and exist) at very first boot stage only. It is disappeared when the system finishes boot process.

Basically, DFU is not a boot loader. When you plug a device with DFU functionality into the host, the host recognize that device similar to a composite device with 2 descriptors: DFU and application functional descriptor. When the host request the device to use DFU functionality, the device will change its configuration to do that...

So, direct to your question, the mouse is not necessary for bootloader at all but it is there because DFU specification requires that:

It is very important to note that the device exposes two distinct and independent descriptor sets, one each at the appropriate time:x Run-time descriptor setx DFU mode descriptor set

 Regards

[OldNick]

Thanks Dekiru

I am trawling through the DFU spec from USB.org (Revision 1.0) and got pretty much the same idea.

If I want to use the DFU class to program an application into a board whose application has been erased or not yet programmed I need a bootloader that only exposes the DFU interface, right? (i.e. boot into DFU mode)

When I make a product, if I want that product to be able to switch to flash download mode via a USB command from the PC, I have to add the DFU interface to my "real" application? (DFU running mode descriptor set)

When the PC wants to download, it sends a detach to the DFU Interface, and then issues a USBreset which kicks my application into running the booloader, right?  At that point, we are back to DFU mode descriptor set.  (i.e. only have to expose the DFU interface?)

Having finished programming the application, the PC issues a USB reset to run the application code.

Unless there is something badly wrong with the PC host transaction model, and it needs to see a DFU running mode descriptor set and issue a "detach" before it can issue any commands on the DFU interface.  That would be sad.

The other possibility that is bothering me is that the appnote code "might" be using the hid class as a data transport for the programming packets.  (In other words, not actually DFU compliant.)  And to find that out,. I am going to have to read the source.

If BryGuy is correct, then what the appnote code does is put both bootlader AND HID application in one binary.  What would be the point of that?  (Unless the PC host needs it as above)

Heigh ho!

[PaoloRenzo]

Hi

As far as I know, the DFU runs as a composite device: in this case an HID and DFU

At runtime, a DFU GUI switches the MCU into DFU only.

After this, the DFU GUI updates the DFU firmware: or in other words -- flashes an application in the rest of the ROM not used by the original DFU+HID device. After this point, if the application loaded is correct, then the application will run instead of the DFU solution (until an external event switch it to DFU again during reset: a button, HW event, whatever)

App note has more details on this. Let me know if this is clear, or if this is causing more questions than answers, I can write that part in a different way.

This DFU implementation supports DFU standard. The HID can be replaced with any other class you want, but you need one for sure.

BTW HID was selected since it requires less FLASH memory and as far as I know, it's supported as a regular usb class, like mass storage (you don't install inf files for usb sticks). It's a composite device in a way to adapt this standard to the low level MCUs with even less flash. Additionally the standard considers that the application being loaded must run usb (which is not a requirement with our DFU implementation). This will give you a clue why the DFU is a composite device and why adding a non-sense HID class with the bootloader is necessary.

Hope this helps

[OldNick]

Thanks Paolo.

I am getting the hang of what it is suppose dto do, so I thought I try it out. 

Sadly, when I tried the appnote on my K40 tower the pll_init locks up.

Same on my Kwikstik.

Same on my real targte (based on tower K40 ref design.)

turns out the clocking of the Tower K60 and the Tower K40 are different.

Any idea how to make this appnote run on a Tower K40?

[Dekiru · Accepted solution]

Hi,

Let's take example that you want to have a MSD device application, and you want to have a bootloader (in this case is DFU) to upgrade your application (like you need to fix bugs in MSD application).

So it will be like this:

1. The first time when you have just flashed DFU bootloader code into the board and plug it into PC. Because there is not any valid example exists yet, the bootloader is run and you will see a composite device (with DFU and HID) on you PC.

2. You download your MSD application to board using DFU GUI, the MCU switches to DFU mode to send/received/flash the chip, then it is reset to run MSD application. At this moment, you see on your PC only the MSD device exists. There is not any DFU or HID.

3. You turn off then turn on your board, the bootloader check and see a valid application (MSD app) so it move to that app immediately. You will not see DFU and HID on your PC.

4. If you want to upload new firmware, you have to tell the MCU that you want to stay at bootloader (by pressing some keys when power on for example (the AN should mention these for boards they took as examples, otherwise user cannot know which switch need to be pressed)). If do like this, you will see only DFU and HID exist, you will not see your MSD app on PC.

You don't need to care about the HID code, it is there to satify DFU specification only. They don't use that for any useful trasaction. You can delete the code in HID callback function to save some bytes of flash

I see the DFU (for microcontroller) is more suitable for usecases in which you don't need to change the whole your app but you want to change an amount of data (like change data for Freescale logo to your company logo, change different font, string.. for different markets)...

The MSD device bootloader will be more convenient and faster than DFU I think. Let's wait for that to be released...

Regards

[OldNick]

Dekiru,

thanks for the help.  Once I can get this running, I will try taking the HID descriptors out and see if the PC app gets upset.

If I remember, I 'll check my answers back in  here.

PS, regarding MSD

I have been trawling through other appnotes as well.

AN4368

AN4379

Are both available. One looks like MSD host, and the other like MSD device.

neither work with the TowerK40.

[OldNick]

Having fun with this...

Does anybody know where to find out the erase sector size of a Kinetis?

Definitions of Fprot registers say each bit covers 1/32 of the total memory.

But have found nothing in the RM or Datasheet so far to say what the erase sector size is.

AN 4370 has a couple of "interesting" defines for K60.

#define IMAGE_ADDR              ((uint_32_ptr)0xA000)
#define ERASE_SECTOR_SIZE       0x800  /* 2K bytes*/

in "bootloader.h" and

#define MAX_BLOCK_SIZE           (24)
#define BUFFER_LENGTH        (MAX_BLOCK_SIZE*40) /* 1K bytes*/

#define MAX_FIRMWARE_SIZE        (0x0007FB00 -  0x13000) /* 200K bytes*/

 in usb_descriptor.h !!!

not sure in which number base 40 * 24 makes 1024 (actually 960?)

And what the heck is going on with 0x7fB00 - 0x13000

Any explanations from anybody would be useful.

[Dekiru]

Actually, it seems to be impossible to find out the 2k sector size in Kinetis's documents.

The later platform like K70 have this information in RM.

We can get this value from many code reference like SSD driver, MQX, USB stack

#define BUFFER_LENGTH        (MAX_BLOCK_SIZE*40) /* 1K bytes*/ =>  they should comment it as approximate 1k

#define MAX_FIRMWARE_SIZE        (0x0007FB00 -  0x13000) =>

                          (1) They estimated that the bootloader will take from 0x00000 to 0x13000,

                          (2) The flash end at 0x7FFFF but they spend last sector for storing firmware size, so they can use till 0x7FB00 only

To port MSD device bootloader to K40 tower or Kwikstik, you have to change clock setting portion. The boot loader was developed based on USB PHDC stack so you can get almost everything from there.

Regards

[OldNick]

Dekiru,

in the interests of sharing info. I found the rest of the "real" app note code in my IAR install directory under arm/examples/freescale/USB

Have borrowed what I wanted, and thrown away the rest.

Now all I have to do is figure out why my code runs fine under Jlink, but hangs in standalone, leaving the chip in a "protected" state.

Something odd about the code path based on reset source - but what - hmm?

[BryGuyH]

The DFU is meant to coexist with your application, that is why the example has a HID present - you are supposed to replace the HID with whatever application you intend on deploying. Obviously you could cludge together a system that only has the DFU present under some circumstances but that is not the intention of the spec. The intention is that there be a way to easily detect a) when a device can be upgraded b) allow your application (on the PC) to upgrade firmware on your device c) do the above with a minimum level of interaction with the user other than a simple prompt.

Ref:

http://www.usb.org/developers/devclass_docs/usbdfu10.pdf

[Dekiru]

I don't doubt about what you explain for HID and DFU existence, but that is for normal use case (like DFU example in Freescale USB stack...

The initiator of this thread is considering about HID in bootloader (AN4370: http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4370.pdf), that is a different case.

Please look at that app note for details.

Regards

[BryGuyH]

Well in terms of USB the simplest and virtually universally driverless device to be is a human interface device (HID). As far as the appnote is concerned its simply there as a demo so you can see when it is and is not working (because the pointer moves)

You can use HID for a miriad of othere puposes though too not just mouse and keyboard.