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.

MSP-EXP432E401Y: Using USB port U7 to be a virtual COM port

Part Number: MSP-EXP432E401Y

I've been trying to setup and use USB port U7 on this board to be a virtual COM port for a few weeks now without much luck.  I've been able to get a couple of the examples (usbdevcserial and usb_serial_device) to work so it's obviously possible, but figuring out how it works so I can implement it in my application is where I'm stumped.

The first problem is figuring out what commands need to be executed to set the port up to be a virtual COM port.  The programs run through a whole lot of steps to initialize but I have no idea which steps are necessary to configure the port and which are not.

The second problem is figuring out how to use it.  I'm hoping to be able to poll it to see when a byte came in and then fetch the incoming byte.  And for outgoing test to see if I can load a byte and when clear load it to be sent out.  The problem here is that it looks like these functions are implemented in interrupt routines in these examples and I have no idea where these routines are located.  Any examples that are not interrupt driven would be very helpful.

Thank you so much for anyone who can help me get past this point.

  • Hi Brad,

    I think usbdevcserial is the best starting place. 

    The first problem is figuring out what commands need to be executed to set the port up to be a virtual COM port.  The programs run through a whole lot of steps to initialize but I have no idea which steps are necessary to configure the port and which are not.

    The example is very minimal so I expect most of the configuration code to be applicable to you. You can experiment by striping down the example to something close to what you need.

    The second problem is figuring out how to use it.  I'm hoping to be able to poll it to see when a byte came in and then fetch the incoming byte.  And for outgoing test to see if I can load a byte and when clear load it to be sent out.  The problem here is that it looks like these functions are implemented in interrupt routines in these examples and I have no idea where these routines are located.  Any examples that are not interrupt driven would be very helpful.

    Using interrupt routines is going to be the best way forward. Do you have external requirements to use polling? If possible I would avoid it. 

    In this example the application code interfaces with the UART module. The UART module is connected to the USB module. The UART ISR is called UART0_IRQHandler in usb_dev_cserial.c

    Regards,

    Evan

  • Hello Evan,

    Thank you for responding.  As I mentioned above, I had already worked with the usbdevcserial example and I hadn't been able to learn enough from it to be able to transfer it's functionality to my application.  But, just to go back to where I left off, I reloaded it into my MSP-EXP432E401Y development board and I am able to talk to it through the usb port U7 with another terminal program.  So I'm back to where I was.

    Just for fun I put some breakpoints in UART0_IRQHandler thinking it might go there when a character was received and nothing happened when I sent characters so I guess I misunderstood your reference to it.

    WRT interrupt routines I want to avoid them as much as possible.  My application has routines that are timed and I don't want them disturbed.  I realize I'm in the minority with this point of view but I think designs are much cleaner, and simpler to understand, when there aren't any interrupt routines at all.  There must be a way to use this functionality in a polled configuration since it is associated with a UART module.

    Thank you for any responses.

  • Hi Brad,

    Thanks for your response. In general TI's example projects will use ISRs. If you want to create an application with a polling architecture then you will have to convert an example yourself. 

    I'm surprised you didn't see the ISR fire. If you look through the ISR you can see with function call it makes to the USB and UART peripherals. You should be able to use that to re-create the functionality in your application. For example, you could poll the interrupt status and then run the handler whenever your application is ready to.

    Evan

  • Hi Evan,

    I just tried setting breakpoints in UART0_IRQHandler again at lines 521, 550 and 556 and it still didn't stop at those points when I sent a character from a terminal program over U7.  It did respond properly to the character so I know it is ok. 

    I also set a breakpoint at line 1722 in the main loop to make sure debug was working properly and it did stop there so we know that is working ok.

    So the question is: Why isn't it stopping in UART0_IRQHandler if that is the routine that is supposed to be called when the interrupt is triggered?

    Can you tell me where I can look to see what routine will be called when any particular routine is triggered?  Maybe it's not UART0_IRQHandler as we expected.

    Thank you,

    Brad

  • Hmm I was expecting the UART ISR to fire, but I'm not seeing it either. 

    However, I think there is still enough in this example to get you going. 

    I think the basics are:

    RxHandlerCmd(...) is a callback function that is registered with the USB module (see usb_structs.c). It is called when a new character comes in. If you want to convert this to a polling architecture you will have to dive into the datasheet and figure out which bit you need to monitor.

    CommandPrint(...) has example of how to send data out through the USB module. 

    I know you said you prefer a polling architecture for your applications timing sensitive code. However, you could try using interrupts for USB communication and disabling interrupts in timing critical sections. Just a thought.

    Regards,

    Evan

  • Brad,

    FYI I will be out of office next week so I may or may not be responsive. I'll be back June 6.

    Evan

  • Hi Evan,

    I followed the execution to see where the incoming bytes were getting picked up. The command at line 461 in usbringbuf.c is where the byte is being put into the command buffer, g_pcCmdBuf located at 0x2000510:

    461 pui8Data[ui32Temp] = USBRingBufReadOne(psUSBRingBuf);

    and, digging deeper, this byte is being picked up from the ring buffer located at 0x2000300 by the command at line 412, also in usbringbuf.c:

    412 ui8Temp = psUSBRingBuf->pui8Buf[psUSBRingBuf->ui32ReadIndex];

    This raises the question: What routine is putting the incoming byte into the ring buffer?

    It must be the interrupt routine and I don't know where the interrupt routine is located. There must also be a hardware setting somewhere that tells the processor to run the interrupt routine whenever a byte is received.

    Can you tell me how to locate the interrupt routine and also the hardware setting that tells the processor to run the interrupt routine whenever a byte is received?

    Thank you,
    Brad

  • Hi Brad,

    Thanks for you patience, I was out last week.

    I believe the USB device interrupt handler is USB0_IRQDeviceHandler() located in C:\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\usblib\msp432e4\device\usbdhandler.c

    Regards,

    Evan

  • Hi Evan,

    Thank you for your response and welcome back.

    I went to USB0_IRQDeviceHandler() in usbdhandler.c to see if I could follow the program flow when it received a character over U7, but when I put a breakpoint at line 66 in that routine execution kept stopping there without any character being sent. So it looks to me that this routine is called periodically whether a character has been sent or not.

    I do want to point out again that what I'm really trying to do is poll for the character, not have it execute an interrupt routine. Is that what USB0_IRQDeviceHandler() is doing and there is no interrupt routine? If so, maybe I need to look at it to see how it is polling for the data.

    If there is still an interrupt routine involved can you tell me how I can deactivate it? I assume that if it is deactivated I can test a bit somewhere to see if a new character has been received and then pick up the character from another register.

    Thank you,
    Brad

  • Hi Brad,

    Given that the function has the word "IRQ" in the name I believe it is an interrupt driven function, not something that is called periodically.

    I know you would prefer to use a polling based approach, however given the complexity of the USB stack required just to get a serial port working I don't think I will be accomplished easily. It is not as simple as an interrupt getting fired when a character is received. Based on a very high level diagram of how the USB API works, it is clear that there is a lot of software between the registers and the application code.

    But if you are determined, presumably you could inspect the contents of the IRQ and determine exactly what you need to do operate the USB peripheral. Perhaps you can perform the same operations but on a scheduled (non-interrupt) timeline. However, I'm nervous about this approach. Based on a quick read-through of the USB handler it appears that interrupts are getting fired for all sorts of events that software/driver needs to respond to and be aware of. I don't know if you could service the USB peripheral often enough to maintain USB protocol correctness if you are just periodically invoking this "servicing function". Furthermore, it seems like a lot of work and this is not an approach that TI officially supports. 

    If you choose to go down this path I would start by giving the USB driver docs a quick read though. You can find them here: file:///C:/ti/simplelink_msp432e4_sdk_4_20_00_12/docs/usblib/msp432e4/users_guide/users_guide-srcs/users_guide/device_functions.html > navigate to USB CDC. 

    Sorry to be the bearer of bad news, but I hope that helps some.

    Regards,

    Evan

  • Hi Evan,

    Ok, you've convinced me that I should use the interrupt functionality if I don't want to spend a lot of extra time that I don't have trying to implement it as a polling function.  I don't like interrupt driven functions because I don't know where they are located, what they are doing, and how much time they are taking.  I like to know exactly what is going on in my designs.

    I'll start implementing it by copying the functionality of usbdevcserial over to my application.  

    But I'm very confused by the fact that when I put a breakpoint at line 66 in USB0_IRQDeviceHandler() execution kept stopping there without any character being sent.  It seems to me that an interrupt routine would only be called when a byte is received.

    Can you clarify that for me?

    Thanks,

    Brad

  • Hi Brad,

    I feel sorry to have convinced you, but I think it's probably the best choice Slight smile

    All the information regarding the interrupts (ie, where, what, and how long) is located in usblib/device directory of your simplelink installation. You should be able to inspect the code to get a rough idea of what is happening. If you are concerned about how long the routines take you could recompile the usblib (or maybe you would have to recompile the entire simplelink lib --not sure) and toggle GPIO pins at key points in the interrupt handler to get an idea of how long things take.

     USB0_IRQDeviceHandler() execution kept stopping there without any character being sent.  It seems to me that an interrupt routine would only be called when a byte is received.

    The usblib defines a lot interrupts, here is a sampling below (taken from usb.h)

    //*****************************************************************************
    //
    // The following are values that can be passed to USBIntEnableControl() and
    // USBIntDisableControl() as the ui32Flags parameter, and are returned from
    // USBIntStatusControl().
    //
    //*****************************************************************************
    #define USB_INTCTRL_ALL         0x000003FF  // All control interrupt sources
    #define USB_INTCTRL_STATUS      0x000000FF  // Status Interrupts
    #define USB_INTCTRL_VBUS_ERR    0x00000080  // VBUS Error
    #define USB_INTCTRL_SESSION     0x00000040  // Session Start Detected
    #define USB_INTCTRL_SESSION_END 0x00000040  // Session End Detected
    #define USB_INTCTRL_DISCONNECT  0x00000020  // Disconnect Detected
    #define USB_INTCTRL_CONNECT     0x00000010  // Device Connect Detected
    #define USB_INTCTRL_SOF         0x00000008  // Start of Frame Detected
    #define USB_INTCTRL_BABBLE      0x00000004  // Babble signaled
    #define USB_INTCTRL_RESET       0x00000004  // Reset signaled
    #define USB_INTCTRL_RESUME      0x00000002  // Resume detected
    #define USB_INTCTRL_SUSPEND     0x00000001  // Suspend detected
    #define USB_INTCTRL_MODE_DETECT 0x00000200  // Mode value valid
    #define USB_INTCTRL_POWER_FAULT 0x00000100  // Power Fault detecte

    I would suspect that another usb event has occurred that is firing the interrupt, such as USB_INTCTRL_SOF

    Regards,

    Evan

  • Hi Evan,

    Does this mean that if I implement usbdevcserial in my application that it will be interrupted continuously even when no bytes of data have been received?

    And if so, can I shut it off and activate it only if I am ready to receive data (which would be very frequently)?

    Thanks,

    Brad

  • I don't like interrupt driven functions because I don't know where they are located, what they are doing, and how much time they are taking. 

    I haven't studied the usbdevcserial to know how the interrupts work, but if you use Exception Profile as part of SWO trace in CCS you should be able to get timing information on when an exception (aka interrupt) is entered or exited.

  • Hello Chester,

    This looks interesting to me but I didn't get very far in trying to use it.

    When I followed the "Exception Profile" link, Step 1 said I needed to make sure the debug probe was in the SWD mode which is set in a Connection Properties box that is part of MSP432-XDS110_SWO.ccxml.

    Can you tell me how to bring up MSP432-XDS110_SWO.ccxml so I can make sure the debug probe is in the SMD mode?

    Thank You.

  • Hi Evan:

    I'm still interested in whether or not I can shut off the interrupt and I've been looking into usbdevcserial further which brings up a few more questions.

    The sampling of interrupts you sent says they are passed to USBIntEnableControl() and USBIntDisableControl() and are returned from USBIntStatusControl(). How are these routines related to USB0_IRQDeviceHandler()?

    Are there a bunch of different routines that are called? Do you know where these other routines are located? If I'm going to implement this functionality in my application I need to make sure all of the routines are included.

    Thank you for your reply.

  • Hi Brad,

    The sampling of interrupts you sent says they are passed to USBIntEnableControl() and USBIntDisableControl() and are returned from USBIntStatusControl(). How are these routines related to USB0_IRQDeviceHandler()?

    USB0_IRQDeviceHandler() is called every time the USB hardware trigger an interrupt. Inside it determines what the actual source of the interrupt was (SOF? VBUS_ERR? etc.). USBIntEnableControl() enables specific interrupt flags, see code below. If you want to disable USB interrupts for a period of time you can do that via USBIntDisableControl(). 

    void
    USBIntEnableControl(uint32_t ui32Base, uint32_t ui32Flags)
    {
        //
        // Check the arguments.
        //
        ASSERT(ui32Base == USB0_BASE);
        ASSERT((ui32Flags & (~USB_INTCTRL_ALL)) == 0);
    
        //
        // If any general interrupts were enabled, then write the general
        // interrupt settings out to the hardware.
        //
        if(ui32Flags & USB_INTCTRL_STATUS)
        {
            HWREGB(ui32Base + USB_O_IE) |= ui32Flags;
        }
    
        //
        // Enable the power fault interrupt.
        //
        if(ui32Flags & USB_INTCTRL_POWER_FAULT)
        {
            HWREG(ui32Base + USB_O_EPCIM) = USB_EPCIM_PF;
        }
    
        //
        // Enable the ID pin detect interrupt.
        //
        if(ui32Flags & USB_INTCTRL_MODE_DETECT)
        {
            HWREG(USB0_BASE + USB_O_IDVIM) = USB_IDVIM_ID;
        }
    

    Are there a bunch of different routines that are called? Do you know where these other routines are located? If I'm going to implement this functionality in my application I need to make sure all of the routines are included.

    C:\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\devices\msp432e4\driverlib\usb.* will have driverlib usb code. 

    C:\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\usblib\msp432e4\ and the subdirectory device will have more usb api code as well.

    Regards,

    Evan

  • Can you tell me how to bring up MSP432-XDS110_SWO.ccxml so I can make sure the debug probe is in the SMD mode?

    In your project for the MSP-EXP432E401Y the target configuration .ccxml might have a different name. By default, when creating a project the .ccxml file will be in a targetConfigs directory in the project.

    If you open the target configuration file in CCS, on the Advanced tab -> Connection Properties set the JTAG / SWD / cJTAG mode to "SWD mode - Aux COM port is target TDO pin":

  • Hi Evan,

    I was able to find usb.c in "C:\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\devices\msp432e4\driverlib" and in it I found "USBIntEnableControl(uint32_t ui32Base, uint32_t ui32Flags)".

    Then I tried to set some breakpoints in USBIntEnableControl thinking it would be useful to know which interrupts were being activated and to learn how they were being activated. But CCS immediatly disabled the breakpoints I was setting saying at one point that there was no code associated with those breakpoints.

    Can you see what I'm doing wrong? Or, is there a better approach I should be taking in order to start implementing the usbdevcserial functionality in my application?

    Thank You.

  • Hello Chester,

    I'm making progress following your direction. Thank you. I can now bring up the Event Analysis tab and it prompts me to setup an event profile when the program starts at main(). I'm interested in the interrupts that are being called so I select Exception Profile and press OK.

    When it starts running it gives me a number of choices but the only one that seems to be very active is Raw Data and it's not clear to me what any of the data it's displaying means.

    I looked at Exception Profile and it had one entry after a few minutes and I didn't know what that meant either.

    What I'm very interested in learning is exactly what interrupts are active and how much time it takes to run them.

    Thank you for any clarification you can provide.

  • Brad,

    Are you importing all the usblib code into your project? If the routines aren't getting built then CCS would complain like you've described.

    Evan

  • Evan,

    This happened in usbdevcserial.  I'm still trying to learn as much as I can about how it works and I haven't started to import it into my application yet.

    Brad

  • Ah ok. It's possible it is not getting used by the lib. What happens if you put a breakpoint in the IRQ handler?

    If you want to know what interrupts are enabled you can alternatively inspect the USB_O_IE register directly.

    Evan

  • Hi Evan,

    I'm going to start copying the functionality from usbdevcserial over to my application.

    Can you give me any guidance on what needs to get copied over in order to get this to work?

    Thank you so much.

    Brad

  • I would start by copying the imports in usddevserial:

    #include <stdbool.h>
    #include <stdint.h>
    #include "ti/devices/msp432e4/driverlib/driverlib.h"
    #include "ti/usblib/msp432e4/usblib.h"
    #include "ti/usblib/msp432e4/usbcdc.h"
    #include "ti/usblib/msp432e4/usb-ids.h"
    #include "ti/usblib/msp432e4/device/usbdevice.h"
    #include "ti/usblib/msp432e4/device/usbdcomp.h"
    #include "ti/usblib/msp432e4/device/usbdcdc.h"
    #include "cmdline.h"
    #include "ustdlib.h"
    #include "pinout.h"
    #include "usb_structs.h"

    Some of those are probably related to the command line implemented in this application, so you may not all of them.

    Then include the SDK in your projects properties:

    Regards,

    Evan

  • Evan,

    I'm making progress but still have a few issues getting this to work. It looks like most of these issues have to do with CCS not able to find things in my application.

    1. First it wasn't able to find cmdline.h or usb_structs.h so I found them and copied them into my project and that seemed to work.

    2. When I ran my application in Debug and tried setting a breakpoint at line 66 in usbhandler.c I got the following error message:

    No code is associated with
    "C:\TI\simplelink_msp432e4_sdk_4_20_00_12\source\ti\usblib\msp432e4\device\usbhandler.c", line 66 in any loaded symbols

    3. It looks like there a bunch of commands from line 1543 to line 1629 in usb_dec_cserial.c that are configuring the usb port in the usbdevcserial example so I started copying some of them into my application. Here is one of them:

    USBDCompositeInit(0, &g_sCompDevice, DESCRIPTOR_DATA_SIZE, g_pucDescriptorData);

    I was able to get it to find the parameters so it compiled ok, but the linker said it couldn't find USBDCompositeInit.

    Thank you for any help you can provide to get me past these issues.

    Brad

  • Evan,

    After my post yesterday, 6/18, I realized I could use Debug in usbdevcserial to find out where USBDCompositeInit is located and I found it in usbdcomp.c.

    When I originally went to include the SDK in my projects properties it was already there so I didn't do anything, but since my project couldn't find usbdcomp.c I thought I should remove it and re-add it to my project. When I did that I got this error message:

    ---------------

    This project was created using a compiler not currently installed - 'TI v18.1.5.LTS'. This
    build-configuration will now be upgraded to a newer compatible version, 'TI v20.2.1.LTS',
    before saving your changes.

    Alternatively, click 'Cancel' and install the compiler 'TI v18.1.5.LTS' before editing these
    settings or select one of the available compiler versions.

    Upgrade the compiler to 'TI v20.2.1.LTS'?

    ----------------

    But when I clicked 'OK' it didn't do anything.

    I also went to www.TI.com to see if I could download 'TI v20.2.1.LTS' to install it manually, but I couldn't find anything about it on the website.

    Thanks again for any help you can provide.

    Brad

  • Brad,

    The way I read that message is that SDK was built with v18. But you have v20 installed. When you included the SDK is asked if you wanted to upgrade it to v20. However, without seeing your steps or the message I'm not entirely sure. 

    Can you determine which compiler versions you have installed?

    Regards,

    Evan

  • Evan

    When I go to 'Help > About Code Composer Studio > Installation Details' I found:

    ARM Compiler Help: 18.1.0.20181119225258
    ARM Compiler Tools: 20.2.6
    ARM GCC Compiler Tools: 9.2.1.2019-q4-major

    I hope that gives you the information you need. I didn't see anything that referenced the compiler version itself.

    Here are the exact steps I took and the error message:

    1. Left-click the project name in 'Project Explorer'.
    2. Choose 'Properties' to bring up properties box.
    3. Choose 'Products' tab which has one entry 'SimpleLink MSP432E4 SDK [4.20.0.12]
    4. Highlight that entry and click 'Remove'.
    5. Choose 'Add' whose box has the entries 'SimpleLink MSP432E4 SDK' and '4.20.0.12'
    6. Choose 'OK' which closes the box.
    7. Choose 'Apply and Close' and that's when I get this exact error message:

    -------------------------------

    This project was created using a compiler not currently installed - 'TI v18.1.5.LTS'. This
    build-configuration will now be upgraded to a newer compatible version, 'TI v20.2.1.LTS',
    before saving your changes.

    Alternatively, click 'Cancel' and install the compiler 'TI v18.1.5.LTS' before editing these
    settings or select one of the available compiler versions.

    Upgrade the compiler to 'TI v20.2.1.LTS'?

    --------------------------------

    And when I choose 'OK' nothing happens.

    It looks to me that it wants to upgrade the compiler to that newer version but is not successful in doing so.

    One other point is that I very, very rarely put that computer online because it is where I do most of my development work and I don't want it online for obvious reasons. I did put it online yesterday on a couple of attempts to upgrade the compiler, but it still did nothing.

    Thank you so much for helping to get me past this point.
    Brad

  • Brad,

    Seems like you have an older version of the compiler. I'm using CCS v11.1.0.00011. Can you make sure you have the latest CCS and simplelink installation?

    I was able to build a project with all the imports from usbdevcserial with these steps:

    Adding the simplelink SDK:

    Adding the following include paths:

    Regards,

    Evan

  • Evan,

    You are right, I have an earlier version of CCS.  My version is 10.1.1.00004.

    As I said earlier I am very reluctant to put that computer online.  Is there a way I can upgrade my CCS without putting it on line?

    Thanks,

    Brad

  • The single file installer should be what you want https://www.ti.com/tool/download/CCSTUDIO

    Evan

  • Evan,

    I installed the new CCS (11.2.0.00007), but when I tried to reinstall the SimpleLink SDK I got the same error message, this time with a slight difference. When I selected Apply and Close there was a box that appeared for a second that said 'Operation in Progress'.  When I tried it again I got the same message.

    The bummer is that when I compile my project it still can't find USBDCompositeInit.

    I was thinking that I might be able just find those files that are needed and just copy them to my project.

    Do you think that would work?

    Thanks,

    Brad

  • I'm not sure. Since I was able to get it to work on my machine you may to experiment and see why this is the case. You may try reinstalling CCS, or trying this process on a different machine.

  • After a more careful reading of the error message, what it's saying is that my project was created with an earlier version of the compiler (TI v18.1.5.LTS) and that is what is causing the problem.  That would explain why you are not seeing the same problem that I'm seeing and why installing a newer version of CCS didn't solve anything.

    I assume it tries to rebuild my project with the newer compiler, but fails for some reason.  I went to 'Project > Build All' to see if that would bring my project more up to date, but the problem was still there.

    Is there another build option that is more comprehensive and would bring my project up to date so it would allow me to include the newer SDK?

    Thank you.

  • What are the errors you are seeing when trying to build your project?

  • I'm not getting errors when trying to build my project.  The error I'm talking about comes up when I try to add the SimpleLink SDK.

    Here is the error message I get when I hit 'Apply and Close' when adding the SimpleLink SDK:

    Please notice that it says that my project was created with compiler TI v18.1.5.LTS and that I need to rebuild it with TI v20.2.5.LTS.

    To be clear, it's my PROJECT that needs to be upgraded, not the compiler itself.  And the problem is that nothing I do gets me past this error message.

    So the question is: How can I rebuild my project such that it's compatible with 'SimpleLink MSP432E4 SDK 4.20.0.12' and I no longer get this error message?

    Thank you

  • Brad,

    What happens when you select v20 in your build settings and then try to import the simplelink sdk? As an example:

  • Evan,

    I selected v20 as you suggested and now I am able to import the simplelink sdk successfully.  Whew!

    But, the linker still isn't able to find USBDCompositInit() which is in usbdcomp.c and usbdcomp.h is in one of the #include statements I put in earlier.  Here is the error message I'm getting:

    All of the includes you suggested earlier are also active:

    I tried a few things, but wasn't able to get past this.

    Do you have any suggestions on how I can diagnose why the linker can't find USBDCompositInit()?

    Thanks,

    Brad

  • What is your linker search path look like? Here's the one in the example. Make sure you have the usblib.a

    Regards,

    Evan

  • The linker was able to find USBDCompositeInit() when I added usblib.a as you suggested.  We're making progress!

    But when I added a couple more of the commands used to initialize in usbdevcserial it ran into more issues finding symbols:

    I went to usbdevcserial and looked at the includes there to make sure they were also included in my project.  My project has all of the includes the usbdevcserial has.

    Thank you for any help you can provide to get me past this point.

  • ControlHander is defined in usb_dev_cserial.c in the example project. I suspect the others are as well.

    Evan

  • Evan,

    I've been able to copy the relevant code over from usbdevcserial and get it to compile and run successfully in my project.  Thank you!  It now works the same way as the usbdevcserial example.

    One problem I'm having is that there is a conflict with my existing code.  The usbdevcserial code uses UART0 and the serial port accessible through the XDS110 debug probe built on to the MSP-EXP432E401Y development board also uses UART0.  I should probably reassign one of these to use UART1 but that doesn't look like an easy thing to do and I'm not sure which one would be the best choice to make the change.

    Please let me know if you have any thoughts on the best way to do this.

    Thanks,

    Brad

  • Hi Brad,

    I'm glad the code seems to be working out for you. I don't have any specific advice about reallocation the UART, it will be up to you to determine what the best approach is. 

    At this point I will be closing this thread. Please respond back if you have new issues or open a new thread.

    Regards,

    Evan

  • Hello Evan,

    Thank you so much for the help you provided.  I wouldn't have been able to get this done without your assistance.

    Brad

  • Brad,

    Glad we were able to solve some problems for you! Good luck with the rest your project.

    Evan