HalCoGen USB Driver Hercules RM48 board

Tammy,

Which board are you referring to? The instructions are applicable to the RM48x HDK which has the RM48L952 MCU on it.

Regards, Sunil

Hi We just got our Hercules Safety MCU Development Kit RM4 MCU board and software about a week ago.  on back of target is printed pcb 4197281 rev e.  Does this help tell you version or can I look it up someplace else on CDs that came with board?  Thank you.

Hi. I forgot to mention, when I exexuted all the steps in example (except the one described above), and hit generate code in HalCoGen, the autogenerated USB files do not compile. All of the other drivers autgenerated compiled perfectly. But so far, a lot of errors when just trying to build as-is following TI example.

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 207: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 207: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 332: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 332: error #258: invalid redeclaration of type name "__attribute__" (declared at line 207)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 332: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 421: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 421: error #258: invalid redeclaration of type name "__attribute__" (declared at line 332)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 421: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 533: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 533: error #258: invalid redeclaration of type name "__attribute__" (declared at line 421)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 533: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 593: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 593: error #258: invalid redeclaration of type name "__attribute__" (declared at line 533)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 593: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 667: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 667: error #258: invalid redeclaration of type name "__attribute__" (declared at line 593)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 667: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 718: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 718: error #258: invalid redeclaration of type name "__attribute__" (declared at line 667)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 718: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 791: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 791: error #258: invalid redeclaration of type name "__attribute__" (declared at line 718)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 791: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 822: error #80: expected a type specifier

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 822: error #258: invalid redeclaration of type name "__attribute__" (declared at line 791)

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 822: error #66: expected a ";"

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 926: error #20: identifier "tUSBRequest" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1282: error #20: identifier "tDescriptorHeader" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1284: error #20: identifier "tDescriptorHeader" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1284: error #20: identifier "tDescriptorHeader" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1289: error #20: identifier "tConfigDescriptor" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1291: error #20: identifier "tInterfaceDescriptor" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1291: error #20: identifier "tConfigDescriptor" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1294: error #20: identifier "tEndpointDescriptor" is undefined

"C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include/usblib.h", line 1295: error #20: identifier "tInterfaceDescriptor" is undefined

35 errors detected in the compilation of "../Drivers/HalCoGen/source/usbringbuf.c".

>> Compilation failure

gmake: *** [Drivers/HalCoGen/source/usbringbuf.obj] Error 1

'Building file: ../Drivers/Biolase/source/adcBiolase.c'

'Invoking: ARM Compiler'

"c:/ti/ccsv6/tools/compiler/arm_5.1.6/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -me --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/Biolase/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/UnitTests/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/IntegrationTests/Drivers/include" --include_path="c:/ti/ccsv6/tools/compiler/arm_5.1.6/include" -g --display_error_number --diag_warning=225 --diag_wrap=off --enum_type=packed --preproc_with_compile --preproc_dependency="Drivers/Biolase/source/adcBiolase.pp" --obj_directory="Drivers/Biolase/source" "../Drivers/Biolase/source/adcBiolase.c"

'Finished building: ../Drivers/Biolase/source/adcBiolase.c'

' '

'Building file: ../Drivers/Biolase/source/sciBiolase.c'

'Invoking: ARM Compiler'

"c:/ti/ccsv6/tools/compiler/arm_5.1.6/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -me --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/HalCoGen/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/Biolase/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/Drivers/UnitTests/include" --include_path="C:/Users/tnoergaard/workspace_v6_0/BiolasePFB_EvalBoard/IntegrationTests/Drivers/include" --include_path="c:/ti/ccsv6/tools/compiler/arm_5.1.6/include" -g --display_error_number --diag_warning=225 --diag_wrap=off --enum_type=packed --preproc_with_compile --preproc_dependency="Drivers/Biolase/source/sciBiolase.pp" --obj_directory="Drivers/Biolase/source" "../Drivers/Biolase/source/sciBiolase.c"

'Finished building: ../Drivers/Biolase/source/sciBiolase.c'

' '

gmake: Target `all' not remade because of errors.

**** Build Finished ****

Tammy that is an HDK, but we use the same PCB on different HDKs because the parts in the Hercules line are pin compatible.

There should be a BGA chip in the top center of this kit.  What is the part # on the BGA?

(It could be RM46xxx or RM48xxx or RM57xxxx - this is the distinction that we need to know)

Hi,

  It is "RM48L952ZWTTYFC-39C8THW"

Thank you.

Tammy,  then to answer part of the question - you were looking at the right instructions since you have an RM48 device.

Not sure what is causing your compiler issue. 

There are some steps in the instructions regarding build options - have you double checked that your project settings matches these?

Hi. So the link is Ok for this target board for USB. I will redo stepbystep again and see if I missed something the first time around. If it does not work still I will zip up USB test project and upload it on here for you too look at. Thank you.

Ok that sounds good.

Hi,

Questions, following steps of link: http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class

- "Step 5: Update stack sizes Since majority of the USBD stack executes in interrupt context, the stack size has to be increased as shown below"

And the screenshot of HalCoGen is shown under RAM tab. But in our Halcogen, we cannot edit any of the fields under RAM tab to increase the stack size.  Was there another step missing or screenshot of where in Halcogen we are allowed to edit and increase the stack size, since under RAM tab these fields are not writeable.

- " Step 6: Configure USB descriptors. Configure USB descriptors and other items specific to USBD CDC Stack. These options are available under the ‘USB’ tab. Note: Since the string descriptors are in Unicode, one must manually convert the ASCII test to Unicode (Eg., 'ABC' should be entered as 'A','0','B','0','C','0'). The character count for each string must be manually updated for size of the Unicode string (eg., Size of A','0','B','0','C','0' shall be 4).''NOTE: The INF file in the example folder uses 0x0451 VID. So use 0x0451 VID, instead of 0x1CBE, in HALCoGen configuration window.'''

Why is this step required? How does this change to make customer specific?

Q3 - this test is configuring Hercules target as a USB client, is this correct?  If we wanted to test with Hercules being USB Host device, how does that differ? i.e., do we replace steps with i.e. USBHost0, enable jumper USBHost0 instead of USBDON, etc.?

Hi Tammy,

Tammy Noergaard said:

- "Step 5: Update stack sizes Since majority of the USBD stack executes in interrupt context, the stack size has to be increased as shown below"

And the screenshot of HalCoGen is shown under RAM tab. But in our Halcogen, we cannot edit any of the fields under RAM tab to increase the stack size.  Was there another step missing or screenshot of where in Halcogen we are allowed to edit and increase the stack size, since under RAM tab these fields are not writeable.

Yeas this is a tricky screen.   The top row in 'Stack Configuration' is a summary - sum of all the various stacks starting with 'User Stack' through 'Undefined Stack'.   You can change 'User Stack Length' and see that it updates the top line; even though you can't change the top line directly.   Would be nice if an 'edit' type control weren't used for this.

Tammy Noergaard said:

- " Step 6: Configure USB descriptors. Configure USB descriptors and other items specific to USBD CDC Stack. These options are available under the ‘USB’ tab. Note: Since the string descriptors are in Unicode, one must manually convert the ASCII test to Unicode (Eg., 'ABC' should be entered as 'A','0','B','0','C','0'). The character count for each string must be manually updated for size of the Unicode string (eg., Size of A','0','B','0','C','0' shall be 4).''NOTE: The INF file in the example folder uses 0x0451 VID. So use 0x0451 VID, instead of 0x1CBE, in HALCoGen configuration window.'''

Why is this step required? How does this change to make customer specific?

This step populates some of the USB descriptors, and controls how the device presents itself to the PC.  I wouldn't make any changes here until you get the demo running the first time.   There is a .inf file on the host side that goes along with this screen and if the two don't match - the demo won't work (it'll be an issue of windows not finding the driver ...)

Tammy Noergaard said:

Q3 - this test is configuring Hercules target as a USB client, is this correct?  If we wanted to test with Hercules being USB Host device, how does that differ? i.e., do we replace steps with i.e. USBHost0, enable jumper USBHost0 instead of USBDON, etc.?

Yes, but specifically a virtual COM port is how it will look to your PC when it's all said and done.

We don't have a USB host example.  The host side software is a lot more complex.  We do have a standard OHCI host controller though and there are various options both commercial and open source for getting this supported.  Have you picked an OS vendor?  That's usually where you would get the host side software from.  

Thank you. yes we are getting this from OS vendor, so we will stick to TI USB Device test then.  We had planned to use all the 64 GIO on the RM48 (GIOA, GIOB, ... GIOH) for our project.  So, in the HalCoGen PINMUX window, we had enabled GIOA and GIOB.  But when I enable USB Device, there are conflicts (GIOA_0, GIOA_2, GIOA_1 and GIOB_3.  Does this mean these 4 GIO pins are not available for us to use for another purpose, because we had to select the USB Device function that need to use these 4 terminals?

Hi Tammy,

Simple answer to your question is yes.  If you have one 'mode' of your product that uses USB and another that could use the pins as GIO then theoretically you could switch the pinmux at runtime like we discussed, but given it's a USB connection this probably won't be practical.

The RM48 device as far as I know also has only GIO ports A and B implemented. 

There seem to be (at least) 2 schools of thought with regards to how to build GIO into a microcontroller.

One is to have generic GIO functionality centeralized (like GIOA, GIOB, .... GIOH) but then use pin multiplexing to control the pin function.    See this more often than not today. 

The other is to build the GIO control registers into the various peripherals.   This is the style that we have on the Hercules family for the most part.   Although we have a bit of a mix.    In this style you will find a set of GIO registers inside each peripheral frame (for example MibSPI, HET, SCI/LIN, DCAN have GIO registers as part of the peripheral).

An advantage of this approach is that you might have something to interface to that can 'almost' work with a MibSPI but let's say it needs to have software toggle a pin at particular times to overcome something missing in the basic SPI protocol.   If you use one of the MibSPI optional pins as this GIO then your driver can be nice and modular - everything it does can interact with just the MibSPI rather than having to interact with a centralized GIO module as well as MibSPI.
 (and the centralized GIO might be shared w. other software blocks).    So I think there are plusses and minuses to each approach.

Note that there are a few peripheral blocks on the RM46 like the external memory interface and USB that don't have the embedded GIO capability though ... so there are exceptions. 

The 'GIO' module that is on the RM46 is included to give us external interrupt capable pins and in some cases to add GIO functionality to pins that use the newer IP modules which were designed for a centralized GIO model.  Otherwise you'll find about the same GIO functionality in the GIO registers that are distributed through the peripherals.

Anyway that's a long winded explanation.   But the reason to explain is you mention using 64 GIO pins and going to ports up to GIOH.     Instead, you're going to need to look at using the GIO ports distributed into the perhipherals.

You can get a lot of GIO out of N2HET so that's a good one to start with.   After the N2HET's the MibSPIs might be another to look at because they can have a lot of IO when you add up the chip select pins and possibly parallel data pins.  

If you need a lot of interrupt capable GIO then you will likely need to use N2HET and have an N2HET program running that performs an edge-detect to interrupt function.

http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spnu503&fileType=pdf  technical reference manual RM48x. wow thank you for the great explanation. we thought we had 64 GIO available for the RM48L952ZWT. Can you check that? If it is only GIOA and GIOB (not GIOA through GIOH which is what we had read in link of manual at the start of this reply) then that means we only have 16 and not 64.  You mentioned NHET. We had hoped to use all 16 "PWM"  in HET1 and HET2. Does that mean we also have to select HET1 and HET2 under the PINMUX HalCoGen window to make sure we have no conflicts (or that some of the PWMs are not available). When we select the HET1 and HET2 under PINMUX, then it adds 12 conflicts (some with USB, some with I2C, and some with SCI and some conflicts between HET1 and HET2 only). Do we have to enable PINMU HET1 and HET2 if we want to use the 16 PWMs, but what does that mean when there are HET1 and HET2 conflicts with each other in some cases (i.e., HET1_5 and HET2_12, etc.)?  So then it is the same, we cannot use all PWMs if we want to use USB, I2C, and SCI for example for the NHET terminals that share functionality with USB, I2C, SCI? What does that mean for the stability of using any of the PWMs via HET1 and HET2 if PINMUX USB is enabled as priority then?

Hi Tammy,

The RM48L952ZWT definitely only has GIOA and B ports.   Apologize if the TRM chapter is confusing; it's somewhat generic and documents the GIO module which can be generated with up to port H.  But on the RM48L952ZWT the instance of the GIO has only ports A and B.   

The best place to understand what is available on the RM48L952 is to study the terminal functions section of the device datasheet.  (SPNS177).   Here you can see in table 2-24 all of the GIO port pins that are available, as well as the pins that are multiplexed with other functions like USB or N2HET.

I think a critical questions are:

1) Do you need 16 PWMs or 32.  I couldn't tell from your mail if you need 16 on N2HET1 and 16 on N2HET2 (32 total) or 16 across the two N2HETs.

2) Do you need to use both USB ports or can you share one port and use it either as a host or device.  (We do not have OTG support, so this would mean something like a normal mode where you are host, and a 'maintenance mode' where you can switch the host into a device, and this only happens rarely.

If you need both USB ports, as well as 32 PWMs then I think it's already very tight based on these requirements.

Sorry to not answer your questions above, but I think the urgent things might change if it turns out that you are already very tight.   If you only need 16 PWMs or can live with one USB port then we can go back to the original line of thought.

Thank you. We had initially hoped for 72 GIO, 17 PWMs (we thought from HalCoGen we could only have 16 total, 8 on HET1 and 8 on HET2, and then we can assign 1 pin of 0..31 to each PWM that does not conflict with another function multiplexed with that terminal), I2C, SCI, and both USBHost0 and USBHost1. 

On the HalCoGen version we have HET1/HET2 Pages each shows a sub page of PWM0-7 (which is why we thought there are only 8 * 2 = 16 total). Then given the PINMUX conflicts with SCI, I2C, USB, etc. -- that limited which actual pins we could assign to each of the 16 PWMs.   So, is it possible to have 32 PWMs on each HET? How is that configured? And is it correct though we can only assign a pin to the PWM in HET1/HET2 that doesn't show as a conflict in PINMUX page?

Hi Tammy,

Each N2HET pin can be programmed as a PWM output, so even if you subtract the pins that are used by the USBHOST ports you could have up to something like 35 PWMs on this part.

I didn't subtract the 2 SCI pins that are muxed with HET because the LIN module is actually a SCI/LIN so you can use it as a UART instead of the plain SCI port.

HalCoGen's black box driver is what you're interacting with when you see 8 PWMs / 8 Edge Detects / 8 Captures.  We include the black box driver to mimic a typical hardware timer so that you can do something useful with N2HET without running straight to the HET IDE and HET programming which can be intimidating.. especially if you are just getting started with the part.      

What sort of PWM requirements do you have?    You can probably get exactly what you want out of the N2HET so it would be good to know your wish list.   However the basic PWM on the N2HET is pretty limited.  (Hard to explain but the period would have to be some integer multiple of some time step like N * 500ns and this step might not be as flexible as you might like for a PWM with a very short period.  On the other hand if the period has some flexibility and is a lot slower then the simplest PWM might work for you.)  

What we need to know are:

   - Period (Range, Resolution/Steps)

   - Duty Cycle (Range, Resolution/Steps)

   - How many of the PWMs can share the same counter.   (You can actually have a different timebase for each PWM with N2HET ... it just takes instructions to implement this).

   - Do you want any special things like complementary pairs,  deadband, etc?

   - Assume you want shadow registers (synchronous updates to duty cycle at period boundaries)?

To your questions:

Tammy Noergaard said:

So, is it possible to have 32 PWMs on each HET? How is that configured? And is it correct though we can only assign a pin to the PWM in HET1/HET that doesn't show as a conflict in PINMUX page?

Tammy Noergaard said:

 And is it correct though we can only assign a pin to the PWM in HET1/HET that doesn't show as a conflict in PINMUX page?

Not exactly.   Yes if there is a conflict, and you need the pin for another function like USB this is true.
But there are 12 N2HET pins that are not multiplexed at all,  for example N2HET1[21:16] are some of the 12..
These pins don't show up in the pinmux tab of HalCoGen at all, but you can assign them as PWM.

Thankyou. I will go back to team to get those answers on PWM requirements. But let us say we only need 16/17 PWMs of the i.e., of the 39 or so pins available on HET1 and HET2 combined.  after we take in consideration the worst case scenario for multiplexing.  Given that we hoped to have 72 GIO and now it turns out with multiplexing we may only have 10 available of GIOA and GIOB total. In addition to adding an external chip as an option for expanding GIO, is it possible to program any of the 39 HET1/HET2 pins that we do not use for PWM (i.e., 39 - 16 = 23) as GIO programmed as either just simply input or output as a GIOA or GIOB pin would function for example? Or even some f those additional pins you mentioned in addition, is it possible to program those to behave as a GIOA or GIOB Input or Output pin would behave to minimize what has to be done off the RM48 in terms of additional GIO?

HET1/PWMs

HET2/PWMs

Hi Tammy,

Yes any of the HET pins not used as PWMs or other timing functions can be used as GIO.

These N2HET pins are also very easy to make act like external interrupts in case you need more external interrupt inputs than what you get from the 10 GIO.

There are still quite a lot of pins that you can use for GIO without resorting to adding an external device.

You can use SPI, MibSPI, LIN, DCAN, RTP/DMM, ECLK, and the ADEVT pins as GIO.    The EMIF WAIT input I believe is input / edge detect capable.   And if you are not using all of the ADC pins but can afford to perform extra ADC conversions, you could use these unused ADC pins as extra inputs.

So let's say something like:

GIO               10

HET as GIO  23

DCAN as GIO 6

LIN as GIO      2

SPI2                5

MibSPI1          5 

MibSPI3          5

MibSPI5         13

ECLK             1

EMIF WAIT     1  (Input / Edge Detect)

AD1EVT         1

That brings you right to about 72.  Now I did that quickly by scanning the pages so it should be checked.

But even on top of this, you can use A/D inputs as 'inputs' if you're willing to convert them.

And there are a number of RTP/DMM pins available as GIO ..  5 from DMM that are not muxed, and 17 RTP that are muxed with EMIF ... so another potential 22 GIO there.   I didn't pick these first because RTP and DMM are not available on the RM46 in case you wanted to scale 'down' in the family but that may not be a care-about in which case you can get some pretty 'wide' GIO ports from these modules.

Unless you also need a lot of these functions (and can't use them as GIO) I think you have a decent shot at hitting the 72 GIO mark.

Hi. Thank You.

1. On USB. After we build the USB Test Code in. What do we need to do with the windows inf file to make the demo work? The test code loops waiting for something over the USB, but is there something special we need to do with the inf file in the example on windows host machine (the wiki does not specifiy what to do with the inf file) to trigger getting something over USB that TI test sw receives as USB device. 

 2. On pwm. you wrote about the black box driver in which the TI pwm test is based on. You asked:
"- Period (Range, Resolution/Steps)
- Duty Cycle (Range, Resolution/Steps)
- How many of the PWMs can share the same counter. (You can actually have a different timebase for each PWM with N2HET ... it just takes instructions to implement this).
- Do you want any special things like complementary pairs, deadband, etc?
- Assume you want shadow registers (synchronous updates to duty cycle at period boundaries)? "

Can we use the black box approach then with pwm scenario as follows (and the remaining NHETS be repurposed as GIO (inputs) as you mentioned), or do we need to use 2nd programming model you described, for i.e.,:
a. pwm1 Hard Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, 75Hz 100Hz, fixed 3mS (duty cycle)
Soft Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, fixed 4mS (duty cycle)

b. pwm2. Frequency synchronized with PWM1, variable duty cycle (0 - 100%)

c. pwm3. (100%) on or (0%) off but need to have the option of 100Hz, 0% to 100% duty cycle, 100 steps controllable

Tammy Noergaard said:

1. On USB. After we build the USB Test Code in. What do we need to do with the windows inf file to make the demo work? The test code loops waiting for something over the USB, but is there something special we need to do with the inf file in the example on windows host machine (the wiki does not specifiy what to do with the inf file) to trigger getting something over USB that TI test sw receives as USB device. 

Hi Tammy,

To be honest I'm not that deep in my understanding of windows drivers.  But there is some info on this page that might be useful if you want to understand it in depth:  http://msdn.microsoft.com/en-us/library/windows/hardware/ff547515%28v=vs.85%29.aspx .

However, I think the 'gist' of this INF file is that it tells windows which driver to use for the HDK, when the HDK enumerates with the VID and PID specified in the .inf file  (%DESCRIPTION0%=TIUSB, USB\Vid_0451&Pid_0002).  

The reason I had suggested getting this demo working as-is first rather than modifying the VID / PID (which is easy to do in HalCoGen) is that it would mess up the host-side .inf file ... you would need to know enough to create your own host side driver.

In the case of our example, it's supposed to be using a built-in Windows Usb Serial driver which I think are what those lines referencing 'usbser.sys' are all about. 

Given all of this, I think what will happen is that when you plug in the HDK USB device port  (not the debug port) windows will want to find a driver for it if it's running the CDC example code.  It should appear with the VID and PID 0451 and 0002.    I believe 0451 is assigned to TI.     Windows won't find the driver file itself so you will need to manually point it at the directory where the .inf file is stored in order to install the driver.   The actual driver already should be on your windows machine (the usbser.sys file) but this .inf links the hardware to the standard driver file.

There's probably a bunch of inaccuracy in the above answer so I apologize.  But give it a try - in device manager or whereever the HDK is showing up try to install the driver for it or do an 'Update Driver' and point to that .inf file.   It *should* then go ahead and assign a COM port # to it and you can use any terminal program like PuTTY or the Terminal program included with CCS to connect to this COM port.

Sorry I don't have the example setup in a way that I can run it at the moment.  But if you have trouble I can try to get my setup up to speed and debug further.   I do remember having some trouble with this example and the .inf file but it was because the VID and PID in the instructions did not match those in the .inf file.   I think I added a comment about this on the CDC example wiki page.

Hi Tammy,

Separate reply on this post to keep the answers from getting mixed up.

Tammy Noergaard said:

. 2. On pwm. you wrote about the black box driver in which the TI pwm test is based on. You asked:
"- Period (Range, Resolution/Steps)
- Duty Cycle (Range, Resolution/Steps)
- How many of the PWMs can share the same counter. (You can actually have a different timebase for each PWM with N2HET ... it just takes instructions to implement this).
- Do you want any special things like complementary pairs, deadband, etc?
- Assume you want shadow registers (synchronous updates to duty cycle at period boundaries)? "

Can we use the black box approach then with pwm scenario as follows (and the remaining NHETS be repurposed as GIO (inputs) as you mentioned), or do we need to use 2nd programming model you described, for i.e.,:
a. pwm1 Hard Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, 75Hz 100Hz, fixed 3mS (duty cycle)
Soft Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, fixed 4mS (duty cycle)

b. pwm2. Frequency synchronized with PWM1, variable duty cycle (0 - 100%)

c. pwm3. (100%) on or (0%) off but need to have the option of 100Hz, 0% to 100% duty cycle, 100 steps controllable

You can try the black box driver out to see if it will work for you. 

It might.   If you run with the N2HET at 110MHz (possible on the RM48L952) then your typical loop resolution period will be 1.16us.

That translates to a worst case error of 0.019% on duty cycles in the range of 3ms and +/- 0.006% on a 10ms period (your 100Hz case).   If that's accurate enough for you the BlackBox driver might work.   On the other hand you could be getting step sizes down to 9ns (instead of 1.16us) on period and duty cycle with a custom N2HET program.    So it depends on what is 'good enough'.

Ok for the other two requirements - pwm2 synchronized with pwm1.  This might be possible with the black box N2HET program, although you might need to write a custom API for the update performed by the host CPU.    Just depends on what else is going on in the system.    Since the periods are very slow (10ms being the minimum period) you can probably get away with updating both PWM periods with the same value based on an interrupt at the end of the period of pwm1.   As long as you trigger this way and update the periods for pwm1 and 2 together in your code, I think they will wind up staying in sync.

Of course here is a case where if you were pushing the performance requirements harder you would probably want to adjust the N2HET program to use the same counter with the same period value for both PWM1 and 2 ... instead of 2 separate counters.   This way the two PWMs could never get out of sync regardless of what the host CPU does.  

On the requirement of 0% to 100% duty cycle - I'd recommend testing this out.  I think there is a limitation with the PWCNT instruction used by the blackbox driver but i don't see this documented so I'd need to check into this.  Will try to simulate in the HET IDE and let you know.

Tammy,  I was able to make the example work.  I added a .PDF with the screenshots step-by-step for getting through the windows driver update as well as a .zip file with the CCS project I used to the CDC example wiki page.

From your post it seemed like you were on the right track, so we still may have an issue.   I didn't ask which version of windows you were using (I tested on Win 7 Pro x64) and also didn't ask if you had your code actually *running* on the target [rather than halted at main()].   If it's not one of these obvious things then maybe you can try the pre-built example I uploaded.   If that still gives you code 29 we'll probably need to get more info on your system.

Hi Thank you. Ok will redo each step again carefully including following your pdf/zip from the start to be sure nothing was missed. There are 2 things I noticed if you think this matters to what is going wrong.

1. We are using HalCoGen 4.01.00. Under the USB Tab (USB General) sections were entered as shown in step 6- (http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class ). However, even when we save the project, everything entered under section "Serial No" defaults back to 0 when we close the project in HalCoGen and reopen. HalCoGen saves and restores the other fields in this tab Ok.
2. In your example, only USB Device is selected under PINMUX. We just added it (last) after we got the other TI tests running. So, in PINMUX tab in HalCoGen PINMUX, AD1EVT, AD2EVT, SCI, I2C and MIBSPI1 are also all checked in addition to USB Device Step 2 - (http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class ) . We were going to have MIBSPI1 running in as according to the notes you gave us in harmony with USB:
NOTE1: MibSPI1 has up to 6 chip selects, and USB only conflicts with 2 (F3,R2) of the 6. We can still use the other 4, if we need these SPI chip selects in the future.
NOTE2: MibSPI1SIMO[0] and MibSPI1SOMI[0] are the base pins of MibSPI1. This is enough for a common 1-bit wide SPI port. USB conflicts with the E18 MibSPI1SIMO[1] and R2 MibSPI1SOMI[1] signals, so we can't use MibSPI1 in the 2-bit wide parallel mode that it supports (this is optional for SPI).
NOTE3: The MibSPI1ENA pin is an optional handshake - it buys us increased throughput (average) by allowing the slave to signal when it is ready for another transfer rather than requiring the master to always wait for the slave's worst case response time when initiating a new transfer. But we don't need to use this signal.
NOTE4: The minimal set of signals for MibSPI1 then are: MibSPI1CLK (F18 / not muxed). MibSPI1SIMO[0] (F19 / not muxed) and MibSPI1SOMI[0] (G18 / not muxed). Just by assigning these pins to MibSPI we get enough functionality for a 3-pin (clock, data in, data out) basic SPI port, plus the capabilities of the multibuffer unit inside the device.

Other then insuring to remove the conflicts on the PINMUX page with MIBSPI1, and of course MIBSPI1Port setting certain pins to GIO rather then SPI. Should we have done more under the MIBSPI1 tab to configure notes1-4 above to insure no conflict with the USB test running successfully? MIBSPI is now configured to the TI MIBSPI test that was in the same directory as where we got your USB test example in HalCoGen which is a loopback test.

3. Machine is a Windows7 (64-bit) Professional SP1. The last thing I have noticed differs from your steps (in pdf) is the  Hercules board does not show up as an unknown Virtual COM Port like it does in your screenshot on Page 2 of your PDF, after it is powered up and connected to PC. It shows up literally as "Unknown Device". Could this be an issue also? This also happens with your test project on the wiki, also when Hercules powers up and connected to PC via USB, the PC also shows it "Unknown Device" and not the "Virtual COM Port" as in your screen shot in the pdf, and the steps to point to directory of .inf file does not result in any changes to driver. Do we need to buy some special driver software for PCs to have the Virtual COM Port feature available when we connect to Hercules board? What type of cable did you use to connect to Hercules, i.e., USB to RS232 (with or without null modem) or USB on both sides and to be 100% certain which USB port on the board (we connected to what is next t power and RJ45 port)?  WIth your project as well, in device manager and g oto device properties it also shows as "unknown device". When we check the hardware IDs to see whether correct PID/VID values are there, it does not show the values in device manager. Why would on our PC with your project with our Hercules boards (we now tested 2 to make sure the 1st did not have hardware problem, same behavior),  the USB device descriptor has not come to the PC - does this mean the firmware did not respond to PC USB device requests? Could our version of Hercules RM48L952 boards require changes to USB demo (clock configuration differences , or device descriptor differences)?

Tammy,

I doubt that HalCoGen is the issue, since I was able to build the demo before with a much older version of HalCoGen.

We'll definitely need to check on the issue of the USB settings not being saved and file a ticket to fix if the issue is still there in 4.0.2 but in the past we've had this issue before on other screens and it was just a 'nuisance' but once you set the parameter again the code generation was correct.

For the pinmux - I'd say just check that you don't have any cases where the USB OHCI port 1 was selected instead of W2FC (USB device).   These two share the same set of pins and it might be easy to mistakenly pick OHCI because it's also USB.

I think your comment on #3 - if this means you are using Windows 7 Pro  (32 bit) might be a likely place for us to have missed something, as most of the TI computers get the 64 bit edition.   I can test my build by plugging into a 32-bit Win7 machine and see what happens.      The .inf file does have different sections for the 32 and 64 bit OS versions...

The other thing that you might want to do is zip up your project that isn't working, and I can see if it behaves the same way on my hardware.

Hi Thank you.

To clarify we are on Windows 7 64 bit machine, SP1. Yes it is your project as is loaded and running now only. With your project from wiki also same behavior as our project -- what differs from your success steps (in pdf) is the Hercules board does not show up as an unknown Virtual COM Port like it does in your screenshot on Page 2 of your PDF, after it is powered up and connected to PC. It shows up literally as string "Unknown Device".

Do we need to buy some special TI driver software for PCs to have the Virtual COM Port feature available when we connect to Hercules board? What type of cable did you use to connect to Hercules, i.e., USB to RS232 (with or without null modem) or USB on both sides (what we did) and to be 100% certain which USB port on the board (we connected to what is next to power and RJ45 port)?

So, with your project as well, in device manager and we goto device properties it also shows as "unknown device". When we check the hardware IDs to see whether correct PID/VID values are there, it does not show the values in device manager. Why would on our PC with your project with our Hercules boards (we now tested 2 to make sure the 1st did not have hardware problem, same behavior), the USB device descriptor has not come to the PC - does this mean the firmware (this is in your project now also from wiki) did not respond to PC USB device requests? Could our version of Hercules RM48L952 boards require changes to TI USB demo (clock configuration differences , or device descriptor differences)? What board did you test with, and how is it different then the boards we bought?

Hi Tammy,

No special cable.  I'm using a USB A to USB B cable.  Not very long, maybe 3 ft.  I've used it plugged into both a HUB and a PC directly.

This is what my board looks like:

I did just talk to QJ who designed this board, and going from Rev D to Rev E the changes are mostly in the 20 pin JTAG circuit (which reset is used) and logos on the silkscreen.   Very minor and nothing that should change how USB behaves.

I am using Silicon revision A, and the board is RM48L950.

When you setup your HalCoGen example,  did you chose RM48L952 or RM48L950? 

So to confirm -- you took the binary from the project that I uploaded, programmed it into your HDK, and you still get 'unknown device'?

Just to check, do you have the files C:\Windows\System32\drivers\usbser.sys,  C:\Windows\System32\msorts.dll and

c:\windows\inf\mdmcpq.inf  on your box?

Tammy,

Super.

For the terminal settings, there are 2 virtual COM ports in play here.

The XDS100v2 B side virtual COM port maps to a real physical UART, this is SCI2 on the RM48. It needs to be 9600n81.
But you only see a few lines of text:

Texas Instruments
HERCULES MICROCONTROLLERS
Little Endian device

To let you know the example is running..

The other COM port is the virtual COM port implemented by the USB CDC driver. As far as I can tell it doesn't matter what settings are used because it just loops the RX and TX buffers back (echo) and there is no real physical UART in the loop here so no physical protocol.

The client side does seem include code to handle the host changing the baud rate, etc. Look for the functions that involve 'LineCoding' in the name. But I don't think they really do anything except change a data structure in memory in this case, because there isn't a physical UART involved.

If this example were modified to do something like drive SCI2 as the physical COM port tied to the virtual com port implemented by the CDC class, then I think it would matter. That might be a good exercise. But I haven't gone past where we are right now as far as the example goes so don't know how to do this.

I *think* this CDC code may have come from 'Stellarisware's UsbLib originally, and that might be a source of documentation. But otherwise as-is when it's coming from HalCoGen it's not much more than an example that wiggles the USB port. I think you might also be better off getting the device driver from an OS vendor if this is an option you have.

EDIT:  By the way, when I tested the CDC driver I setup PuTTY for 115200, n81.  I didn't try any other settings - so it's just a theory that they don't matter...

Tammy,

Tammy Noergaard said:

However, even when we save the project, everything entered under section "Serial No" defaults back to 0 when we close the project in HalCoGen and reopen. HalCoGen saves and restores the other fields in this tab Ok.

Just to follow up on this - I submitted a ticket SDOCM00114334 regarding the Serial # being blank.  And I was able to reproduce this as well.

Hi Tammy,

These issues are things we need to verify and file tickets on so they get fixed ASAP.

I think the settings are saved in the DIL file and it is processed when you open your HCG file again.

I have noticed that if there is an issue in the settings, it usually displays an error when you open the HCG and the DIL file is read.

When you have the pinmux error - do you happen to see any error messages displayed upon loading?

They scroll fast so you might have to scroll up to check.

For example, with the serial no it looks like this:

Hopefully it's also reporting an error for your pinmux case, and you could then check this screen as a way of knowing if the pinmux info is lost.

Hi Thank you.

When we open HalCoGen there is no clear error box pop up. It was just something we noticed also for that screen. The changes are usually not saved (sometimes but i.e., the last 3 times I have opened HalCoGen, redo changes in USB and PINMUX and close then reopen project after closing HalCoGen and restarting it -- it defaults back to our changes not saved). That's why I mentioned it, was do we need to methodically check each submenu each time to make sure we have our changes in there before autogenerating in case it is more than just these 2? In output menu, there are errors reported looks like the USB Serial  No. and it is what is defined in TI wiki is what we have as entry there. Also,  why are our PINMUX settings not being saved when only USB error for this string reported?.  Errors are:

error - unexpected char: '''

DRIVER.USB.VAR.USB1_SERIAL_NUMSTRING.VALUE='

error:expected ID,NUMBER, or STRING

Hi Tammy,

Curious - did you save your project or generate code before exiting (which seems to trigger a save..) when the

loss of pinmux settings occurred?

I notice that HalCoGen will let you exit with unsaved changes and not issue any warnings.   Guessing that this might be what is going on.

As far as putting some sort of control or check in place you could keep the files under version control and then inspect the pinmux changes
and other changes in a 'diff' program between updates.

The settings are visible in plaintext in the .dil file, for example one of the pinmux lines might look like this:

DRIVER.PINMUX.VAR.PINMUX10.VALUE="PINMUX_BALL_N19_AD1EVT | PINMUX_BALL_N15_ETMDATA_19 | PINMUX_BALL_N17_EMIF_nCS_0 | PINMUX_BALL_M15_ETMDATA_18"

And as long as your project is pretty stable, checking the changes in the dil file from pass to pass through HalCoGen might be a good way to
ensure that something unexpected didn't change.

Hi Thank you. We always do a a File -> Save Project.  But PINMUX page configuration and the one field in USB is not save at all. What do you mean? Is there a special sequence of actions we need to do to insure these 2 are saved. The USB we got the setting from the wiki page, so is there a different entry for serial in order to not get this error?

Hi Thank you. Yes as follows:

Step 1: checkboxes:

USB Host 0
USB Device
AD1EVT
AD2EVT
SCI
I2C
MIBSPI1

Step 2: Resolve 4 Conflicts

E18 (removed MIBSPI)
F3 (removed MIBSPI)
G19 (removed MIBSPI)
R2 (removed both MIBSPI)

On the other note (related to PWM NHET black box versus other programming model). Were you ever able to determine if we could use the black box programming model of NHETs for the scenario I posted? Just a copy and paste from the previous post to refresh your memory. You wrote you would look into it below:

             Tammy Noergaard

. 2. On pwm. you wrote about the black box driver in which the TI pwm test is based on. You asked:
"- Period (Range, Resolution/Steps)
- Duty Cycle (Range, Resolution/Steps)
- How many of the PWMs can share the same counter. (You can actually have a different timebase for each PWM with N2HET ... it just takes instructions to implement this).
- Do you want any special things like complementary pairs, deadband, etc?
- Assume you want shadow registers (synchronous updates to duty cycle at period boundaries)? "

Can we use the black box approach then with pwm scenario as follows (and the remaining NHETS be repurposed as GIO (inputs) as you mentioned), or do we need to use 2nd programming model you described, for i.e.,:
a. pwm1 Hard Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, 75Hz 100Hz, fixed 3mS (duty cycle)
Soft Mode: 5Hz, 8Hz, 10Hz, 12Hz, 15Hz, 20Hz, 25Hz, 30Hz, 40Hz, 50Hz, fixed 4mS (duty cycle)

b. pwm2. Frequency synchronized with PWM1, variable duty cycle (0 - 100%)

c. pwm3. (100%) on or (0%) off but need to have the option of 100Hz, 0% to 100% duty cycle, 100 steps controllable

(TI)

You can try the black box driver out to see if it will work for you. 

It might.   If you run with the N2HET at 110MHz (possible on the RM48L952) then your typical loop resolution period will be 1.16us.

That translates to a worst case error of 0.019% on duty cycles in the range of 3ms and +/- 0.006% on a 10ms period (your 100Hz case).   If that's accurate enough for you the BlackBox driver might work.   On the other hand you could be getting step sizes down to 9ns (instead of 1.16us) on period and duty cycle with a custom N2HET program.    So it depends on what is 'good enough'.

Ok for the other two requirements - pwm2 synchronized with pwm1.  This might be possible with the black box N2HET program, although you might need to write a custom API for the update performed by the host CPU.    Just depends on what else is going on in the system.    Since the periods are very slow (10ms being the minimum period) you can probably get away with updating both PWM periods with the same value based on an interrupt at the end of the period of pwm1.   As long as you trigger this way and update the periods for pwm1 and 2 together in your code, I think they will wind up staying in sync.

Of course here is a case where if you were pushing the performance requirements harder you would probably want to adjust the N2HET program to use the same counter with the same period value for both PWM1 and 2 ... instead of 2 separate counters.   This way the two PWMs could never get out of sync regardless of what the host CPU does.  

On the requirement of 0% to 100% duty cycle - I'd recommend testing this out.  I think there is a limitation with the PWCNT instruction used by the blackbox driver but i don't see this documented so I'd need to check into this.  Will try to simulate in the HET IDE and let you know.