This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/RM46L852: Adding a USB port to the RM46L852

Part Number: RM46L852
Other Parts Discussed in Thread: TMDSRM48HDK, RM48L952, HALCOGEN, TMDXRM46HDK, LAUNCHXL2-RM46

Tool/software: Code Composer Studio

I have your launchpad XL2-RM46 with a RM46L852 processor. I have added a prototype USB (device) port connected to J11 on the board. J11 has all of the USB device port signals. I am seeing correct signals on all lines with the exception of the W2FC_SE0O (pin 15 on the processor, and J11-17, and J5-2 on the booster pack site 1).

I know that the software works because I tested it on the TMDSRM48HDK with a RM48L952 processor. The software is from "processors.wiki.ti.com/.../File:Halcogen_usb_cdc_example_worked.zip" that is based on the article "HALCoGen USB Device - driver & CDC Class" at "processors.wiki.ti.com/.../HALCoGen_USB_Device_-_driver_&_CDC_Class

When I plug the RM46L852 USB port into a Win10 box, I get an error message that "USB device not recognized". I have debugged it down to the W2FC_SE0O pin not functioning - there is no signal on that pin in my prototype, where there is a signal on the TMDSRM48HDK. I have disconnected the pin on the TMDSRM48HDK (in the PINMUX in HALCOGEN); when I do, the unit gives the same error as the XL2-RM46 with my prototype USB board. I have also disconnected that signal from my prototype board, and I still see no signal on the W2FC_SE0O pin (I thought maybe my prototype board was shorting out the signal).

It appears like that signal is not connected in the PINMUX but it is.

Any ideas as to why the W2FC_SE0O pin would not function on the RM46L852 processor?

Prototype board with interface chip (W2FC_SE0O pin-2 on left connector is disconnected for debug):

SE0O scope shot, note the scale of 100mV/div. If I put it on 1V/div, it just looks like a little bit of noise:

  • Hello,

    There is a clocking change between RM48x and RM46x related to the USB device module:

    On RM48, the 48MHz clock required by the USB device is driven on the VCLKA3 clock domain:

    On RM46, this 48MHz clock is driven on the VCLKA3_DIVR clock signal, so VCLKA3 needs to be configured as a faster signal that is then divided down (default is /2) to get 48MHz.

    Let me know if this helps.

  • Please note also that I get the same signal on W2FC_SE0O if it is connected to my prototype or not.

    Also note that I know that the pin works because I switched it over to a digital output in the PINMUX and toggled it in a loop and the output toggled as expected. (I switched it back).

    Here is a screenshot of the signal W2FC_SE0O working on the  TMDSRM48HDK that works (is recognized as a CPC device):

    And a closeup:

  • Thank you for your response.

    I have PLL2 set to 48MHz and selected as the VCLKA3 Src. Then VCLKA3 Divider is set to 1, so VCLKA3_DIVR is 48MHz. Should this be okay?

  • Thanks. The clock settings look correct. Did you check your schematic against the TMDSRM48HDK schematic?

  • Yes, I have closely compared schematics. Everything works but the SE0O line.

  • Here is the schematic, including the J11 pin numbers used for interconnect:

    7271.USB Port Schematic.pdf

  • Have you had any more ideas as to why the SE0O line would not function?

  • Unfortunately, no. I think you mentioned that a physical connection issue is ruled out by configuring the pin as N2HET1[22] and toggling the output. Can you confirm that you can see this pin toggle correctly on the connectors J5/2 as well as J11/17?

    I am trying to get access to this development kit to verify correct operation: 

    I will post an update once I have access to this and have verified the correct operation.

  • I have the development kit with the usb port (TMDXRM46HDK) already working. The board I'm having problems with is the LAUNCHXL2-RM46. I have added a prototype usb port and the SE0O line is not working on that board.

    If you get a TMDXRM46HDK and get the usb port working, you are duplicating my effort. This is not what I need help with. What I need help with is understanding why the SE0O line is not active on the LAUNCHXL2-RM46.

    Thanks.

  • Can you confirm that you have the code working on the RM46HDK and not on the RM48HDK? The part used on the TMDXRM46HDK is identical to that used on the LAUNCHXL2-RM46, so there is no reason from the MCU perspective for the code to work on one and not on the other.

    The only possibility is an error in the physical connection from the connector to the USB port.

  • It's confusing...

    I have the code working on the TMDXRM48HDK (48L952) that has a USB connector built into the board.

    I have ported and tested the same code on the LAUNCHXL2-RM46 (46L852, no built-in USB connector, and has my prototype built onto it to add the usb port) and it doesn't work. The SE0O line has no signal.

    I have disconnected the SE0O line from my prototype and still see no signal.

  • To insure that there is nothing wrong with the processor or board, I purchased a new LAUNCHXL2-RM46 and wired my prototype USB board up to it. It still doesn't work:

    Here is a scope shot of the SE0O line set up as a digital output and toggling in a loop. I am looking at J5-2 with the scope. The signal looks the same on the prototype board. So the pin works. There is some setup problem:

    Do you have any other ideas about clocking? Or anything else?

    This is the TMDSRM48HDK that works. I'm using the same code on both units.

  • The same code on both RM48 and RM46 does not work. Refer to my earlier post about the clocking differences related to the VCLKA3 clock domain that drives the 48MHz clock required by the USB device module.

    On RM48, VCLKA3 is configured to be 48MHz and no other divider configuration is necessary to drive the 48MHz to the USB device module.

    On RM46, if VCLKA3 is still configured to be 48MHz, the VCLKA3_DIVR needs to be configured to be divide-by-1 to drive this 48MHz to the USB device module. The default value of this divider is divide-by-2, so if you are running the identical code between RM48 and RM46, it will not work.

  • I have ported the code between devices, meaning that I modified (in HAL) the clock divider and PLL as necessary to provide 48MHz to the USB subsystem (screenshot attached above).  I have also selected the correct device in HAL when I ported the code. So, the code is not "exactly" the same, with the exception of clocking and pinout setup done through HAL.

    The default value of the VCLKA3 divider is 1, btw.

    I'm guessing at this point that it is a hardware issue because I'm seeing error packets in my analyzer data stream (952 (working, and 852 non-working files attached). Well, your system won't allow me to attach a file now... I'll post this and try to attach on the next post.

  • After a great deal more investigation, I have found that the SE0O line is not active on the launchpad LAUNCHXL2-RM46 with the RM46L852 processor.

    It is low and pulses high upon connection on the TMDSRM48HDK. But it is idle on the LAUNCHXL2-RM46.

    Do you have any further ideas as to why this can be?

  • I found the problem: it is in the pinmux.c file written by HALCoGen.

    Below in pinmux.c, I have commented out lines 254, 256, 257, and 258. These lines hard code the pin function to something other than the USB port functions. The comment on the code is: /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

    The error exists when it writes for the RM46L852 (144 pin gull-wing) , but not for the RM48L952 (384 pin BGA).

    After I commented out these lines, presto the SE0O line started working, and the USB port was recognized by Windows.

    How do I fix this? HALCoGen will just keep writing over my comments each time I rebuild the code... How do I "Hard Code" this back in the USER CODE sections to work with the HALCoGen GUI, and not get overwritten?

  • Thanks for the report, I will file a bug for HALCoGen for this issue.

    As for generating code using HALCoGen, you can use something like this:

    /* USER CODE BEGIN (4) */
    
    #if 0
    
    // incorrect code follows
    
    /* USER CODE END */
    
        /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
        PINMUX_SET(0,1,GIOB_3);
        /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
        PINMUX_SET(0,2,GIOA_0);
        PINMUX_SET(1,5,GIOA_1);
        PINMUX_SET(3,15,HET1_22);
        PINMUX_SET(18,125,HET1_14);
        PINMUX_SET(18,126,GIOB_0);
        PINMUX_SET(21,133,GIOB_1);
        
    /* USER CODE BEGIN (5) */
    
    #endif
    
    // correct code here...
    
    /* USER CODE END */
    

  • Thank you for the code fix.

    Is a new version of halogen in the works?

  • I will have to check with the tools' support team for a confirmation on any update. We will definitely add this to the list of known issues in the "Release Notes" document.

    Regards, Sunil

  • When is a new version of HALCOGEN going to be released?

  • Hi Charlie,

    This is not planned at this time. I will post an update should this change and an update is indeed planned.

  • I gotta say, this make me sort of nervous since it is so old. It supports freeRTOS, but only a very old version. Is Hercules a viable, long term, no-obsolescence plans for the product line? Or should I be looking at another one of your product lines?

  • TI's product longevity support plan is documented here: www.ti.com/.../product-life-cycle.html

    We have new programs being designed using Hercules MCUs with production starts even after 2026, and there are no current obsolescence plans for this product line.

    We look at HALCoGen bugs and determine whether they can be addressed with a "known issues" document update, and make an update plan if there are no reasonable workarounds possible.

  • That is very good to hear; I have invested a lot in this product to use it in a new product line.