Going to try writing a USB Bootloader for JM60

[TurboBob]

Well, I'm going to try to create one.  The only issue that has me worried is USB interrupts while in boot mode.

I have 2 ideas: 

The first is to build the bootloader with the complete USB stack built in,  and not put the stack in the app.  The app would call the functions in the boot sector.  An array of function pointers in a known spot will take care of the ap being able to find the functions to call.  Then the bootloader would forward all interrupts based on a relocated vector table similar to the AN2295 implementation for the HC08AP. 

The PC side would relocate the vectors before sending the file to the device.   Or the bootloader could handle it. 



The second idea would be to use the standard JM60 vector relocation feature,  build the USB stack into the bootloader, but also the app (space is not an issue).  Then when boot mode is triggered, re-write the vectors to point the USB interupt into the bootloader.  Then after loading,  reset the vectors to run the ap.

I have the HID mode of the CMX stack working reasonably,  so I will be using that mode.


Any feedback?

Bob

(note, most of these ideas came out of various conversations and threads on this board, and with board members.  It is not my intention to take any credit.  I plan to post the code when done)

[pgo]

Dear TurboBob,

The USBDM software contains a In-circuit-programming mode that allows reprogramming of the majority of the flash over USB.  This would be easily extracted if it the functionality that you require.

It consists of a minimum USB stack + Flash routines in the protected area of the Flash with the majority of the Flash free for the user code.

See

Combined TBDML/OSBDM Code for the JM16/32/60 (USBDM)

if interested.

bye

[TurboBob]

thanks for the input.  I will look it over.

I was looking over the AN3561 which incorporates a bootloader.

The source code doesn't appear to be part of the .zip file,  but instead its a .lib

Does anyone have the source?


Also,  since the cpu will only be doing boot-loader tasks, I wonder if the USB interupt flag could be polled instead of actually using the interupt.  The longest latency would be due to a sector erase. 

This way the vectors can be handled using just the redirection mechanism..


Bob

[pgo]

Dear TurboBob,

The USBDM bootloader code uses polling while the main code uses the re-directed interrupts, so yes it is possible

I didn't like the AN3561 code since it wasn't open source and also seemed to require Vista or a specific version of XP service pack.  At least I couldn't get the driver to load under XP SP2.
 
bye

[TurboBob]

Current status:

Well, I built up the basic bootloader framework using the CMX stack configured for HID.

The project doesn't actually do anything yet, just runs an empty loop.  But it fits in 6290 bytes of flash.

Code:

void main(void) {  MCU_init(); /* call Device Initialization */  asm SEI;                             /* Disable interrupts */  if(PTBD_PTBD3 != 0)     // if PB is not pushed when powering up. then     {                     //  jump to user ap.    asm       {      ldhx 0xDFFE   ; load vector from user app      jmp ,x       }    }                                                                                          // ------------------------------------initialize USB  usb_cfg_init();  set_mode(dm_generic);  HID_init(500, 0);  out_report=hid_add_report(rpt_out, 0, 64);  //   in_report=hid_add_report(rpt_in, 0, 64);    // //----------------------------------------------------------------------    for(;;) {    /* __RESET_WATCHDOG(); by default, COP is disabled with device init. When enabling, also reset the watchdog. */  if(hid_report_pending(out_report))    {    hid_read_report(out_report, USB_Report_Out);    }  if (!hid_report_pending(in_report))   // if transmitter is not busy.      {                                               //  load up a new message;      }  hid_process(in_report);        if(INTSTAT & INTENB) // USB interrupt bits, detect enabled interupt    {    usb_it_handler(); // this function will service the USB and clear the flag bits    }  } /* loop forever */

 

Yes,  6290 bytes  Way too big, especially considering the application code will have a duplicate USB stack built in.  One possibility for improvement would be to create a way for the app to use the bootloader's USB stack.  It seems like an uphill battle though.

It looks like the ICP portion of the OSBDM is very compact.  It would make a good standalone bootloader except that I don't know how to talk to it.

In contrast, I built up the JM version of AN2295 uart bootloader, and its tiny.  Got it together in 1/2 hour. 

Bob

[TurboBob]

Well,  its obvious to me that my version is way too large.  And I don't have a good enough understanding of the USB stuff to write something anywhere near as clean as your ICP routines in the OSBDM.

I used some of the OSBDM ICP stuff, got it in and functioning (checksum, ICP trigger detection and vector tables).  Very nice.

I need to get the MCG configured (8 mhz xtal) and my LED I/O.  But its a very clean setup.  (great work, thanks a ton).

I need to figure out what I need to publish for the GPL.  I also need to figure out how to talk to it. 

Thanks pgo,  this will really help.

Bob

[TurboBob]

Another update. 

I have the ICP routines integrated into my application.  It boots properly either jumping to ICP if I hold the button depressed, or to the main app.  The checksum calculation works properly.

I added 3 files to my project,  changed user_vectors to match the ProcessorExpert generated vectors.  I modified the PRM file.  A few other tweaks and it builds. 

When jumping to ICP, it is recognised properly, and Windows will install the driver and seems happy.

Now, on to the Windows side of it.  I am trying to integrate the DLL into my Borland C++ Bulider application but am having issues with unrecognised external symbols.  I think its a compatibility issue with non-standard name mangling.  I will let you know how it goes.  Perhaps it would be better to build it as a standalone console app.  If you have any suggestions, let me know. 

I do have Visual Studio 2002 available for use if that is more compatible with the OSBDM sourcecode.

Thanks!

Bob

[TurboBob]

cool,  I was thinking that it should work.

I am going to set it up using generic HID,  so there are no drivers or even an INF file to worry about.

Thanks for the input.

Bob

[pgo]

Dear TurboBob,

I can't see the advantage of a generic HID since you presumably need a driver for the device when operating as the application.  Can't you just use the same driver when in bootstrap mode?

bye

[TurboBob]

My main ap is Generic HID,  so I was planning to use the same driver.  (or non-driver in this case.. )

Considering my tight timeframe ,  I may have to just use the UART bootloader (AN2295) for now.  And change to the USB loader later.

Thanks for the help!

Bob