8-bit MicrocontrollersのトピックMC9S08JM USB, HID with PE.

MC9S08JM USB, HID with PE.

TurboBob — Sat, 06 Sep 2008 06:01:58 GMT

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

Re: MC9S08JM USB, HID with PE.

TurboBob — Sat, 06 Sep 2008 13:17:12 GMT

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

Re: MC9S08JM USB, HID with PE.

TurboBob — Sun, 07 Sep 2008 11:18:27 GMT

Ok, I have it sending data to the PC (HID monitor program)

But, it seems that its taking a huge chunk of processor time to handle the transaction. Is this typical?

I am trying to send 32 bytes at 10hz. it seems like the hid_process() call is taking a ton of time.

Any feedback guys?

Bob

Re: MC9S08JM USB, HID with PE.

TurboBob — Sun, 07 Sep 2008 11:37:20 GMT

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

Re: MC9S08JM USB, HID with PE.

JimDon — Sun, 07 Sep 2008 23:05:54 GMT

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.

Re: MC9S08JM USB, HID with PE.

TurboBob — Sun, 07 Sep 2008 23:31:37 GMT

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

Re: MC9S08JM USB, HID with PE.

TurboBob — Sun, 07 Sep 2008 23:35:19 GMT

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

Re: MC9S08JM USB, HID with PE.

JimDon — Mon, 08 Sep 2008 01:00:44 GMT

I have not tried any of this, but my idea is that you would do the USB send then not do the 'while' until the next time you wanted to send data, the idea being that perhaps the data has already been picked up by the time you get back.. This may or may not be helpful.

Also, going up to 64 byte packets could be helpful, as it takes just as long to send 64 as 32 from your point of view. If you make the changes, make sure you force the entire project to rebuild. For some reason CW does not always do this correctly.
There are several places you need to change the packet size.

What I do is acquire data on an interrupt thread into buffers, then send them from the foreground. I don't think that the USB interrupt should take long, it does not seem to affect me, but then I am running on a V2 at 80MHz that has DMA. Still, I think there are dedicated buffers on the 08.

Re: MC9S08JM USB, HID with PE.

TurboBob — Mon, 08 Sep 2008 01:49:09 GMT

Good info, I think I can get it all to work.

I have moved up to 64 byte packets.

It seems the send takes about 4ms, for now its not impacting things too much.

I think I have a handle on how to re-configure the hid_process() function. A case specific solution looks pretty straightforward. A general case solution is a little more involved to handle the situations of multiple IN reports.

I will post my findings.

Thanks for all your help! HID bootloader is next....!

Bob

Re: MC9S08JM USB, HID with PE.

TurboBob — Mon, 08 Sep 2008 12:21:23 GMT

Another question, now that I have it working I noticed that 2 entries appear in the list of Device Manager, and when I plugged it into my other computer to see if Windows would find it it seemed like it found both my device and a HID (2 notification balloons popped up from the system tray).

Is this normal?

Bob

Re: MC9S08JM USB, HID with PE.

Nik — Tue, 09 Sep 2008 06:45:05 GMT

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

Re: MC9S08JM USB, HID with PE.

JimDon — Tue, 09 Sep 2008 07:36:27 GMT

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.

Re: MC9S08JM USB, HID with PE.

Nik — Tue, 09 Sep 2008 09:08:45 GMT

Thanks Jim,

That's a good idea about using the DEMOJM.

Thanks,

Robert

Re: MC9S08JM USB, HID with PE.

Nik — Tue, 09 Sep 2008 22:30:12 GMT

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

Re: MC9S08JM USB, HID with PE.

JimDon — Tue, 09 Sep 2008 22:44:15 GMT

What you want is a http://www.pemicro.com/products/product_viewDetails.cfm?product_id=33&CFID=2131355&CFTOKEN=89878079" rel="nofollow" target="_blankUSB-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.

Re: MC9S08JM USB, HID with PE.

TurboBob — Tue, 09 Sep 2008 23:00:38 GMT

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

Re: MC9S08JM USB, HID with PE.

JimDon — Wed, 10 Sep 2008 18:25:08 GMT

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.

Re: MC9S08JM USB, HID with PE.

TurboBob — Wed, 10 Sep 2008 20:20:10 GMT

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.

Re: MC9S08JM USB, HID with PE.

JimDon — Wed, 10 Sep 2008 21:11:29 GMT

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.

Re: MC9S08JM USB, HID with PE.

ok2ucx — Wed, 10 Sep 2008 21:32:58 GMT

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