MC9S08JM USB, HID with PE.

[TurboBob]

I have recently switched to exclusive use of Freescale parts, mostly due to the Codewarrior and Processor Expert toolset.  The 9S08JM parts arrived on the scene at exactly the right time for my current projects.

However, in attempting to integrate the CMX USB code into my projects, I keep hitting snags.

In a perfect world, there would be a HID bean in PE,   their serial port beans have worked well for me and integrate into the projects without issue.

Can one of the USB+JM gurus on the board (Jim Don,  Nik, bitwork) help me a little with getting the CMX stuff to work?  The example code is full of conditional configurations which makes it a pain to sift thru to find what I need to change.  The code is expection a bit of file-structure and sub-directory arrangement that I keep stumbling over.

I would really like to use HID, as it is "driverless",  CDC would be the next choice as it only needs an INF.

Has anyone boiled the code down to a couple files that can be added to a PE proiject?  I am continuing to spin my wheels here.

Thanks guys,  there have to be a ton of people with the same problems,  so any hints posted will help the masses.  A good example is the mini-ram versions of the flashing routines (thanks Jim) that have helped countless folks.

Thanks in advance,

Bob Bailey

[Nik]

Hi Bob,

I'm glad that you got this worked out.  Don is the guru here, I'm afraid that my advice would just add confusion.

Don:

We are just now stuffing our prototype board.  It won'thave the P&E BDM module that's included on the DEMOJM.  Will the USBSPYDER08 work?  I see that it says: "The USBSPYDER08 supports RS08KA, S08QD and S08QG microcontroller families.."

Thanks,

-

Robert

[JimDon]

Well, if you mean me, I'm not sure I deserve guru...

In any event, I don't know the answer to that for sure.
My experience with the Spyder was not so great. For one thing it is very slow, and there is virtually no support for it, in terms of other chips. If it does not say that it does support the chip, (which it doesn't) then don't expect it to.

If you do have a demojm, that will function as a full P&E BDM.
Just remove the daughter card, solder in a 6-in head and get 6-pin flat cable.

[Nik]

Also,

We are 9S08JM60 in a development product which might have to ship with a programmer. 

Or we'll have to recommend one.  So it looks like the USBMULTILINKBDME may be the one.

This isn't a Freescale product, but has the 9S08JM60 on it.

Thanks,

-

Robert

Message Edited by Nik on 2008-09-09 04:30 PM

[TurboBob]

What we really need now is the HID bootloader...... 

I think I know enough to make a stab at it,  I am trying to decide whether to make reflashing part of my application, or a separate project like AN2295.  Processor Expert is going to add additional complication.

My current struggle is that if the vectors are redirected, then we will be replacing the USB interupt vector when we reflash the software..  So we can't use it during the bootload process......  I have not figured out how the other USB bootloader app notes get around this.  Perhaps the bootloader USB routine can poll the interupt flag fast enough to work.  Can the vector redirection be turned on and off? 

Bob

Message Edited by TurboBob on 2008-09-09 12:01 PM

[JimDon]

Well you will always have a problem when it comes to re flashing the boot loader code.
You basically have to cache it and do it all at once.

As for vectors, there are several ways this has been handled.
1. Transparently redirect vectors. When the "user" wants to flash a vector, you put it else where then have code that jumps there at interrupt time.

2. Recognize that the vector table is about the be re flashed, and pause the download until this is done. If the usb device goes off line, then you may need to restart things. Good pc code can handle a dis-connect re-connect. Also, you protect your vectors and always make sure they go back to where you need them to be.

[TurboBob]

Ok,  I understand about replacing the bootloader code.  I'm not planning on doing that.

Correct me if I am wrong,  but if we relocate the vectors using the HCS08 internal mechanism, then all of the interupt vectors move to below the protected flash.  So if our bootloader is e800 - FFFF (roughly) then all of the vectors are at ~E7F0, including the USB vector.

So, like the method in AN2295, we can use the PC loader program to handle the vectors and make sure they are written to their new spot if necessary, but when we are almost completely re-flashed, the last block to be received will contain the vectors,  including the USB vector currently being used to receive the data.

I suppose we could download to RAM a full sector, then pause the USB, jump to RAM, erase the segment, program/verify, then resume.  Tricky but do-able.  I just need to make it unbreakable.

Bob

What is your feeling on building in the bootload function vs. making it a separate project?  By making it built in, we can assure that the VID/PID are the same so there is no DEVICECHANGE when switching over to bootloader mode.

[JimDon]

I don't know that there is anything that guarantees when you will see the vector code, so you may have to snoop for it.

It would not be a bad idea to have a linkable boot loader module.
On the other hand a special vid/pid for a boot load app might be good too.

[ok2ucx]

Dears,

there's USB AN2295 bootloader made for HC908JW32. It exists for few years already as a part of AN2295SW source tree. Written in C. Works.

True, you need to handle reflashing the interrupt vector tables, in JW32 case there are actually three tables:

#1 [boot_table] First vector table is the "working" one, i.e. here the original ones are redirected to.
#2 [bl_boot_table] Second, the bootloader's one - the complete table gets copied (flashed) to #1 BEFORE USB Bootloader starts its USB activity.
#3 [usr_boot_table]Third one, here the user interrupt vectors will be put (relocated & flashed) during the bootloading. After the bootloader is finished (and all USB activites are stopped), these fresh user vectors will get copied (flashed) to space #1 and the user code will start.

Since this is all included in the AN2295SW source tree, you can inspire in there.

Regarding S08JM60, AN2295 USB bootloader will be developped within next few months, possibly also for ColdFire family.

Regards, Pavel

[TurboBob]

Good evening,

Is there any update on the USB version for the JM60?

Thanks

Bob

[McMadtown]

The CMX usb.c file states that endpoints 5 and 6 can only be double buffered in iso and bulk mode, not interrupt (HID.)   Does anyone know if that is true? The data sheet says nothing of the sort.

I was planning on double buffering at least one of them as more of a safety measure than anything else. Is anyone else doing that? Or is the HID spec so slow/limited that it's pointless to double buffer?

Also I'm assuming that it's not smart to use the Init_USB bean in PE when using the CMX USB stack. Since both attempt to initalize the endpoints etc.  Right?

Thanks!

Kevin

[Nik]

Hi,

Sometimes the debugger won't display a local variable.  I get "undefined expression" if I try to add it manually.

Any ideas?

Thanks,

-

Robert

[JimDon]

Chances are it does not exists, as it was optimized away into a register variable.
Try declaring it volatile while debugging.

[Nik]

Ahh, thanks, that was the problem.  This was a return value of a function that did not have a forward declaration, that is why it was optimized away.  Thanks Jim.

[JimDon]

What you want is a http://www.pemicro.com/products/product_viewDetails.cfm?product_id=33&CFID=2131355&CFTOKEN=89878079"...USB-ML-12 from P&E Micro.
I would buy them directly from P&E.

That is an FSL part number, but you will get it for a few dollar less if you buy it from P&E.

[Nik]

Thanks Jim,

That's a good idea about using the DEMOJM.

Thanks,

-

Robert

[TurboBob]

Ok,  I managed to integrate it with my processor expert project.  It was a bit of a fight but now it compiles and the PC recognizes the device.

There are some other errors going on, as it doesn't seem to be sending data to the PC.

Any suggestions are appreciated,  I will post my progress.

Bob

[TurboBob]

A quick summary of the files required to get this to play nice in PE:

drag the USB-DRV folder into the files pane

into the user modules folder in the files pane I dragged:
hid_usb_config.h
hid.c
hid.h
hid_usb_config.c
target.c

There is the issue of PE wanting to generate the isr vectors.  I used an interrupt vector bean to create a USB vector to usb_it_handler.  there is still a clash when running the bdm loader, but it works.  (vector is defined twice)

I edited the following
hid_usb_config.h:    EP0_PACKET_SIZE
hid.c                         MAX_REPORT_LENGTH
hid_usb_config.c     the descriptors and message length stuff
target.c                   i put this in for the interupt enable and disable functions.

I configured the CPU bean for the proper clock settings

in my application I put the following calls in for initialization
usb_cfg_init()
set_mode(dm_generic)
HID_init(500,0)

out_report = hid_add_report(rpt_out,0,1)

in_report = hid_add_report(rpt_in,0,32)

in my main endless loop I put:
hid_process()

in a 100ms task I put the report loader
if(!hid_report_pending(in_report)
{
...... fill up bytes in array USB_Report_In[32]

hid_write_report(in_report,USB_Report_In);
}

the above are the basics as I remember them......


Bob

[JimDon]

In the hcc_u8 geh_config_descriptor, the USB_FILL_EP_DESC, the last value should be 1 for a 1 ms poll time.

It could take up to 2 ms to process, but if you are on a high speed bus you should get a 1 ms time. Note that long or poor quality cables can also increase this time due to retries. Other activity should be interrupt driven.

It is also possible that you could have hid_process() not wait for the packet to go and then wait when you need to send the next packet.

[TurboBob]

On your other suggestion,  all of the tasks are interrupt driven, but since the 08 has only one interupt level, I can't perform any long tasks in the ISR.  These are done in the main,  and long delays prevent the real time control tasks from completing on time.....

At any rate, things are looking good, 

Bob

[TurboBob]

The poll time change made a major improvement.

I think, however, that your second suggestion is important as well, as this device's main function is not USB.  USB is for control and datalogging.  I don't want it waiting for the packet to go.

In hid_process() would you change the while loop to something else?  Or should I set a status bit that the packet is pending and clear it after the packet goes?

Thanks for your help

Bob