DFU with Freescale PHDC USB stack (bootloader)

[davebv]

Hi everybody,

I am leveraging what to use for a device of which firmware is meant to be upgraded via USB.

The current options are:

- The already available bootloader (AN3561) which uses a vendor class (0xFF)

- Make a bootloader with the PHDC stack using the DFU class which is standard for this operation as I understand.

I 'd rather using the PHDC solution since I use it in the whole project. My questions are:

- What part of the stack should I keep in a non-writable flash area? The whole stack or just part of it?

- What should I do in the case the PHDC is upgraded? Should it be possible to re-write the bootloader from another program? Would it be correct?

Thanks for helping me clarifying everything on this topic.

[nonarKitten]

Having used AN3561 extensively, I can say it works well enough and is very reliable. The only real down side is that you're dependant on driver installation. We're planning on going WHQL, so ixnaying the iversdray would be a huge plus. So we're in the same boat.

1. Sharing code between the bootloader and application code is generally considered a bad idea, although to be fair, if the bootloader did contain the entire PDHC library, and it's protected anyway, I can't see the harm in doing this

2. The PDHC is rather **heavy** for a bootloader. I would start, instead, with the JM60 Mouse Demo and make a bootloader from there. The HID implementation from FreeScale is 1/10th the size of either the PDHC or CMX stack

That being said, HID has it's problems too. If you pick a packet size smaller than the flash, you need to add a routine to reassemble them in order. HID makes no promises about reports arriving in order, or on time. If you make the packet the size of flash, then you may run into issues as I'm not sure the tony FreeScale stack can handle reports bigger than a single packet. But I may be wrong -- I've just never tried it.

[davebv]

Thanks for your reply.

In my opinion the downside of having to install the driver is not really an issue since we already have to install another driver for using our application with the phdc stack.

While I am trying to shrink the code of the phdc stack I was not able to reduce it, just the dfu class doubles in size of the whole AN3561 bootloader.

I do not like either the idea of sharing the code of the stack for the application, and the bootloader. Not being able to upgrade the stack itself for the application. I considered the HID option but it has more problems than advantages, at least for me.

I think based on your advice, I will try with the AN3561.

Thanks for your help.

[davebv]

Using the AN3561 leads me to another question about vector redirection:

If I have used all my interrupt declarations such as:

void interrupt VectorNumber_Vusb USB_ISR_vector(void)

and

void interrupt VectorNumber_Vrtc rtc_isr(void)

How would I be able to redirect those to be located in the proper vector table?

I would like to avoid using a new vector for example:

void (* volatile const _Usr_Vector[])()@0xFBC4= {    RTC_ISR,          // Int.no.29 RTC                (at FFC4)    Dummy_ISR,        // Int.no.28 IIC                (at FFC6)    Dummy_ISR,        // Int.no.27 ACMP               (at FFC8)    Dummy_ISR,        // Int.no.26 ADC                (at FFCA)    Dummy_ISR,        // Int.no.25 KBI                (at FFCC)    Dummy_ISR,        // Int.no.24 SCI2 Transmit      (at FFCE)    Dummy_ISR,        // Int.no.23 SCI2 Receive       (at FFD0)    Dummy_ISR,        // Int.no.22 SCI2 Error         (at FFD2)    Dummy_ISR,        // Int.no.21 SCI1 Transmit      (at FFD4)    Dummy_ISR,        // Int.no.20 SCI1 Receive       (at FFD6)    Dummy_ISR,        // Int.no.19 SCI1 error         (at FFD8)    Dummy_ISR,        // Int.no.18 TPM2 Overflow      (at FFDA)    Dummy_ISR,        // Int.no.17 TPM2 CH1           (at FFDC)    Dummy_ISR,        // Int.no.16 TPM2 CH0           (at FFDE)    Dummy_ISR,        // Int.no.15 TPM1 Overflow      (at FFE0)    Dummy_ISR,        // Int.no.14 TPM1 CH5           (at FFE2)    Dummy_ISR,        // Int.no.13 TPM1 CH4           (at FFE4)    Dummy_ISR,        // Int.no.12 TPM1 CH3           (at FFE6)    Dummy_ISR,        // Int.no.11 TPM1 CH2           (at FFE8)    Dummy_ISR,        // Int.no.10 TPM1 CH1           (at FFEA)    Dummy_ISR,        // Int.no.9  TPM1 CH0           (at FFEC)    Dummy_ISR,        // Int.no.8  Reserved           (at FFEE)    Dummy_ISR,        // Int.no.7  USB Statue         (at FFF0)    Dummy_ISR,        // Int.no.6  SPI2               (at FFF2)    Dummy_ISR,        // Int.no.5  SPI1               (at FFF4)    Dummy_ISR,        // Int.no.4  Loss of lock       (at FFF6)    Dummy_ISR,        // Int.no.3  LVI                (at FFF8)    Dummy_ISR,        // Int.no.2  IRQ                (at FFFA)    Dummy_ISR,        // Int.no.1  SWI                (at FFFC) };

Again, thanks for the help

[bigmac]

Hello,

Many devices - you do not say which one you are using - are capable of automatic vector redirection  to a user vector table located within the highest unprotected flash sector.  However, this is all or nothing, except for the reset vector which is not redirected.  This means that, should the bootloader require the use of any interrupt, automatic redirection cannot be employed.  In this case, the bootloader must provide the redirection code for every interrupt available for the device.

Some of the issues associated with this approach are discussed here.

Regards,

Mac

[davebv]

Thanks for your answer. I am using the JM32. What I have done already is redirect the vector interrupt to the highest unprotected space, in this case, from FBC0 to FBFF. So far, I have defined my functions like this: interrupt 29 void isrRtc(void); Which by default it puts the value of isrRtc into FFC4. What I would like to know if there is an automatic way of upgrading the redirected vector address (in this case will be FBC4) to the value of isrRtc. What I have to do is create the table I posted in my last post, or modify the .prm file like this: VECTOR ADDRESS 0x0000FBC4 isrRtc .... and so on with the rest of interrupts. Is there any way of defining interrupt functions to be located in the corresponding rom address whenever I use the program with the bootloader or standalone? Thank you

[bigmac]

Hello,

You will need to check this out, but I seem to recall that AN3561 bootloader does automatically reposition the vector table.  You would therefore write your code as if the vector table were at the usual position, starting at 0xFFC0.  The bootloader will then program the actual vector table to the flash sector immediately below itself (starting at 0xFBC0).

The NV data setting (above the bootloader code proper) will enable automatic redirection per section 4.5.7 of the datasheet, but this will also mean that the bootloader cannot make use of any interrupts.

Regards,

Mac

[davebv]

I tried not to place my interrupt functions inside a vector declared like:

void (* volatile const _Usr_Vector[])()@0xFBC4= {isrVrtc,}

 Or use the prm file to modify the vector table:

VECTOR ADDRESS 0x0000FBC4 isrVrtc...

 And looking at the memory contents, there is no reference of the functions in that address. However, I can see the reference to the isrVrtc funtions is still in the 0xFFC4. Since the NVOPT_INIT is set to redirect the vector, no interrupt functions are executed.

My interrupt functions are declared like this:

interrupt VectorNumber_Vrtc void isrVrtc(void);

 What I wanted to do is if there is an automatic way of telling the compiler to locate the interrupt pointers in the redirected flash address (in this case 0xFBC4-0xFBFF) without  modifying the prm or using another vector.

Thanks for your answers!

[Tsuneo]

Hi davebv and bigmac,

I found that Freescale has recently released an appnote of USB HID bootloader.

AN4252: USB HID bootloader for the MC9S08JM60
http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4252.pdf?fpsp=1
http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4252SW.zip?fpsp=1

This bootloader code is easily modified for JM32.

I believe this bootloader is established better than those of AN3561
- The bootloader is independent from application firmware.
- The bootloader occupies the code FLASH of $F800 - $FFFF (2KB), including the original interrupt vector table (IVT).
- The original IVT is redirected to $F7C4-$F7FF. The bootloader doesn't use interrupt at all.
- RAM space is not shared. Entire RAM space is assigned to the current process, bottloader or application.
- A short code dispatches bootloader and application firmware at the prolog of start up.


If I would apply some modification to this code,
- I'll declare 512 bytes (FLASH page size) Output report
- The commands are carried over Feature reports, instead of Output reports
- I'll add Start page program command, which supplies the start page address of FLASH to be erased/programmed, when an Output report comes from host.

Tsuneo

[davebv]

Tsuneo, thanks for your comment.

I am trying this bootloader also. A great advantage of using an standar class so no driver installation is needed.

I think 2k of rom space is ok with me too, coming from trying to use the phdc stack (about 12k!!!)

I will try your suggestions. Thanks