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.

TM4C123GH6PM: Doubt about USB interrupt, and uDMA USB.

Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: BQ25890

Hi,

I made my own device with a TM4C123G and an accelerometer (ICM20689). This board has a USB connector and SD card to log data.
I implemented the usb_dev_msc example with the accelerometer routine that takes values by acc's interrupt (sample rate 1K).
I don't know why windows never detects and mounts the SD, but if I disable acc's interrupts, windows detects perfectly the SD card and I can download files.


I put ROM_GPIOPinWrite (up/down lines) into handler interrupt routines to see them with logic analyzer. But i don't identified any patron.

I don`t understand very well how the usb interrupt works and USB uDMA.


Any hints about this means?

Thanks in advance.

Andrés

  • Hello Andres,

    May be a priority issue. If the Accelerometer interrupts fire often and are higher priority, than the USB bus communication may be interrupted or too slow.

    There isn't a lot of information here for me to be sure about that.

    USB information is included in the USB Library User Guide which is SW-TM4C-USBL-UG-2.1.4.178.pdf located in the docs folder for TivaWare.

  • Hi Ralph,

    Thanks you for the answer.

    I changed the interrupt priority with ROM_IntPrioritySet(INT_USB0, 0x00) but nothing. It's the same.

    Best regards,

    Andrés

  • Hello Andres,

    Have you tried disabling the accelerometers interrupts just for USB initialization and then turned them back on? Would be an interesting test to see if its just the enumeration process or the USB interface as a whole that is struggling with that interrupt running.

    Also what is the ISR for the accelerometer doing?

  • Greetings,

    Agreed - data provided appears insufficient for an "in-depth" analysis.

    Might you clarify:

    • your custom board/boards includes: MCU, Accel., & the SD Card/connector - is that true?
    • all 3 are included so that your board/boards may acquire Accel data, "Free from the PC."   Is that true?
    • if I've described your system correctly - has this worked?   (i.e. when not connected to the PC.)

    Now at some point you, "attach your board(s) to the PC" - this is done so that you may transfer acquired Accel data (stored w/in the SD card) via USB - to the PC.    Again - is this correct?

    Does your system "Break" when:

    • connected to the PC 
    • regularly (even continuously) acquiring Accel data
    • and transferring the Accel data between MCU & SD Card (& even the PC)

    Is it required to (both) "Store Accel data to the SD Card while (near) simultaneously passing data to the PC?   As an alternative - the SD card could be removed from your board(s) (after data acquisition) - & simply plugged into the PC.    Other than "stand-alone" data acquisition - the role of the SD Card appears uncertain...

    It should be noted as well - early use of the µDMA (prior to basic design success) is a clear violation of "KISS" - that extra (often unwanted) complexity - often disrupts (otherwise) sound design efforts...

    Your mission's "intent" is unclear - usually that must be "locked down" prior to MCU design/development...

  • Hi Ralph,

    1- Yes, I did that, and it worked, but I think it's kind of "hardcoded"

    2- My system reads the accelerations in the 3 axes via SPI and saves them in a buffer. For this test, inside while (1), I do nothing, it's empty.

    Hi cb1,
        
    My board has MCU, Accel., the SD Card/ USB connector, RF Xbee (disabled in the code) and a BQ25890 (works independently).
    My system reads the accelerations in the 3 axes via SPI and saves them in a buffer, IF it receives a signal via RF, the buffer is written to the SD.
    Yes, the system works fine. I can save data into SD perfectly.
    My system breaks when I connect the USB before it receives the signal via RF. I didn't try connecting the USB while writing to SD, but I don't think I'm going to allow that option.

    Thanks in advance.

  • Hello Andres,

    And you were able to communicate fine with the USB device after? Like, able to download files etc.? If so, then at least we understand that the interrupt during enumeration is the problem.

    How important is reading the SPI data out in the interrupt? That sounds like a good amount of processing. Could you simplify your ISR to set a flag that data needs to be read and then handle that in the while(1) loop? If so, see if that resolves the USB issue and also provides you accurate data.

    I would think that setting the USB interrupt priority would have been enough to avoid the issue of the ISR taking too long, but it could be that the SPI read process executing within that ISR is more difficult to interrupt. Just taking some guesses here based on what's being presented, it is a bit strange to me still that the priority didn't help, but just trying to get some more potential ideas out so we can figure out what is going on and what will work best for your system.

  • Hello Andres,

    Looking at the D/S I think all interrupts start w/ Priority 0x00.

    Try setting this as well:

    ROM_IntPrioritySet(INT_SSI0, 0x40); 

    (Note, I'm guessing SSI0 is your accelerometer interrupt, if not, use the right SSI channel for that!)

    That would lower the interrupt priority so only USB is higher.

  • Thank you - we must note that the presence of the RF Xbee is new - and even after description - the exactness of its use is unclear to me/my group.

    We remain uncertain as to:

    • when & why your board system connects (via USB) to the PC   
    • the frequency and/or duration of that connection  (possibly the percent of operational time in which the "Connection to the PC is enabled.")

    There appear to be "many moving parts" in this design & the timed sequence (& duration) of critical operations is (thus far) somewhat beyond our understanding.   (don't hate us - yet a clear "block diagram" - overlapped & cohesive system timing diagram - and a narrative well describing (even detailing) all critical operations - is what we normally would request from "official" clients.   And has been proven to work quite well!)

    And not to be forgotten - the complexity of µDMA - introduced while "issues continue" - would not be our firm's recommendation...

    In such (likely) "Timing Challenged Designs"

    • slowing transfer rates
    • while (as/if possible) confining individual operations to "discrete time-slots" (even if that may not be "allowed" in the final design)

    have most always well served to: "first identify (vital) & then systematically 'drive toward' a real solution."

  • Hi Ralph,

    The acc's interrupt is int pin's acc (not SSI interrupt), if I disable this int when i plug the USB everything is OK.

    when int pin is up -> read via spi and put values in a buffer -> when the buffer has 100 values AND I received a msg via RF -> write SD

    I agree that a change of priorities should work, but I do not understand why it does not work. Because I also suspect that it depends on a matter of timing.


    This is my USB Handler interrupt:

    void USB0DeviceIntHandler_spilba(void)
    {
        ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_PIN_3);
    
        #warning
        GPIOIntDisable   (GPIO_PORTE_BASE, GPIO_PIN_5);
    
        USB0DeviceIntHandler();
    
        ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0);
    }

    Interrupt priorities:

    // USB
    ROM_IntPrioritySet(INT_USB0, 0x00);
    
    // ACCEL
    ROM_IntPrioritySet(INT_GPIOE, 0x40);

    Hi cb1,
        
    I connect my board to PC to download the data acquired. When? After or before the data is logged.
    The RF module works as an external enable flag, but is not enabled for this test.

    My testing sequence is (for now i don't use the RF module, it's all quoted):

    main {
    		init ssi
    		init acc
    		init sd_card
    		init usb
    		init interrupts
    
    		while(1)
    		{
    		}
    	}
    
    init interrupts
    {
    	init int pin acc
    	set interrupt priorities
    	enable int
    }
    	
    acc int
    {
    	read via ssi values and put it in a buffer
    }
    
    init usb
    {
    	//
    	// Set the USB stack mode to Device mode without VBUS monitoring.
    	//
    	USBStackModeSet(0, eUSBModeForceDevice, 0);
    
    	//
    	// Pass our device information to the USB library and place the device
    	// on the bus.
    	//
    	USBDMSCInit(0, (tUSBDMSCDevice*)&g_sMSCDevice);
    
    	// Register USB interrupt handler
        USBIntRegister(USB0_BASE, USB0DeviceIntHandler_spilba);
    	
    	//
        // Initialize the state to idle.
        //
        g_eMSCState = MSC_DEV_DISCONNECTED;
    
    
    	//
    	// Configure and enable uDMA
    	//
    	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
    	ROM_SysCtlDelay(10);
    	ROM_uDMAControlBaseSet(&sDMAControlTable[0]);
    	ROM_uDMAEnable();
    
        //
        // Enable Peripheral Clocks
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
        ROM_SysCtlUSBPLLEnable();
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
        ROM_SysCtlDelay(10);
    
        //
        // Enable pin PD5 for USB0 USB0DP
        //
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_5);
    
        //
        // Enable pin PD4 for USB0 USB0DM
        //
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_4);	
    	
    }

    Thanks in advance

    Andrés

  • Hi again,

    My group appreciates your patience - know that (both) vendor agent & my "band of outsiders/trouble-makers" wish for you to succeed.

    We wrote earlier of the "Extra Discipline" we (usually) request of clients (that's been long proven to yield our fastest, best & most complete diagnostics) & while you've done a generally "good job" in responding - serious questions & concerns remain.   Note that there is, "No real Right or Wrong" here - yet you, vendor agent & my group approach your issue from different perspectives & sometimes w/differing methodologies.

    We suspect that it proves wise to start w/several of our "general goals & beliefs."    Should these conflict w/your own - we will need to find some "common ground."   Note too that the vendor agent's "general sense" and that of my group - in general - appear to have converged!    That's "telling" as Ralph zero's in on "MCU code design" while my group attacks the (more general/broader) "design's: foundation, intent, & overall execution."   Thus - when our "suggestions overlap" - most always we are, "Getting Close!"

    Ralph wrote, "How important is reading the SPI data out in the interrupt?    That sounds like a good amount of processing.   Could you simplify your ISR to set a flag that data needs to be read and then handle that in the while(1) loop?   And we wrote, "Can you confine your major functions to, "unique time-slots?"   We are both concerned that such, "function overlaps" prove difficult to fully & properly manage!

    My group's general rules for program success:

    • Give your program (every) chance to succeed!   Avoid potential "over-stress" - apply "KISS" (simplify, role out functions individually, then measure & verify - only then combine & integrate - proceed systematically...) - employ (slowed) conservative timing & where/when possible - "limit function overlaps"  (at least until the general logic & program-flow has been proven)
    • Know that frequently the requirements themselves need deeper management & flexibility (i.e. must often "adapt" for situations that hadn't been anticipated)
    • Be alert to, "Premature Optimization" - too often this introduces "errors/delays" & the end results may prove, "Less than hoped!"

    Now to your program's specifics - forgive me - yet the management & intent of various program tasks seems curious.   Follows a "chronologically based" (starts from your 1st post) listing of my group's "uncertainties:"   (take a deep breathe)   

    • You wrote, "I don't know why windows never detects and mounts the SD, but if I disable acc's interrupts, windows detects perfectly the SD card and I can download files".

    What files?    Is it not true that the SD card handles (only) "Sensor Data?"    (to be complete - we must "probe" for all such (unexplained) details.)

    • "I put ROM_GPIOPinWrite (up/down lines) into handler interrupt routines to see them with logic analyzer.  But i didn't identify any pattern."    

    You should have!  (identified such a pattern)  Code below reveals:

    void USB0DeviceIntHandler_spilba(void)
    ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 8);   //  "sets" PB_3 & is placed atop this function
    ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0);   //  "clears" PB_3 - is placed at function's end -  pattern for sure

    • "The acc's interrupt is int pin's acc (not SSI interrupt), if I disable this int when i plug the USB everything is OK."  

    And this spurred Ralph to write, :"Have you tried disabling the accelerometer's interrupts just for USB initialization and then turned them back on?"

    • "Yes, I did that, and it worked, but I think it's kind of "hardcoded""

    Pardon - but this is "disturbing!"    Both Ralph & my group had suggested "Time-Slotting" (i,e, Strive for one function at a time) yet you offer up, "hardcoded" - minus any definition!   That's self-defeating - is it not?

    It demands to be asked, "Why have you created the situation in which the PC "attaches via USB" while the Accelerometer is "machine-gunning" interrupts?    (Even after observing that this CAUSES your ISSUE!)    Note: - my intent is (not) to be harsh - but to stress the (questionable) logic - displayed by enabling "Acc Interrupts" to continue during the PC-Attach time-frame.    You (should) have complete control - we cannot understand, "Why this OVERLAP was allowed?"

    One last point - despite its added complexity - "uDMA continues" - that's surely, "Premature Optimization" - and may invite issues - should be added (only) after, "All proves well."

  • Hi cb1,

    First at all, thanks for your understanding and supporting. Let's go step by step.

    It's true that it's a good amount of processing unnecessary.

    I log the data into text files, and I use the USB connection to download this files.

    When i wrote "i didn't identify any pattern", I meant that I expected a pattern in the USB interrupt (more or less slow times)
    I attach the images:

    with acc interrupt


    without acc interrupt



    Maybe the solution is like Ralph wrote, "disabling the accelerometer's interrupts just for USB initialization and then turned them back on"

    But "USB initialization" means when I connect the USB?


    You wrote "One last point - despite its added complexity - "uDMA continues" - that's surely, "Premature Optimization" - and may invite issues - should be added (only) after, "All proves well." "

    I do not understand well what it means

    Thanks in advance.

  • My friend, 

    Got it - thank you.   Language may well play an issue - my team notes yours as quite good.   (far beyond my (assumed) Spanish...)   (we born "el norté" have it "so easy" - language wise.)

    andres_dalmati said:
    It's true that it's a good amount of processing unnecessary.

    I'm not suggesting that your processing is "unnecessary" - instead might it be "Less than optimally managed?"

    To my group's (collective mind ... all of us) - you have "Made NO case" for "Allowing the PC-USB connection" while "Continuing Accelerometer Data Acquisitions!"   And this proves especially bothersome as you "recognize this 'Fault-Causing' linkage" - yet allow it to continue!   Why is that?    (Never explained nor justified!)   

    My firm also produces a, "Multi-channel, hi-speed, data acquisition board/case" (via 2 ARM Cortex M7s) into (both) SD card & USB stick - yet we find little (i.e NO) need to do so - when/while attached to the PC!    And to enhance operation - we include a compact OLED (display) & "5-way, miniature, tactile "Joy-Stick!

    andres_dalmati said:
    Maybe the solution is like Ralph wrote, "disabling the accelerometer's interrupts just for USB initialization and then turned them back on"

    Indeed - that has a "reasonable" chance (yet not a guaranteed chance) of succeeding."   However - even better - simply "Cease accelerometer's OPERATION during the PC-Connect interval!"   That's (both) more secure, far more direct & easier - than (only) disabling interrupts!    (which then - somehow - have to be re-enabled!)    And is one means to achieve a "Distinct Time-Slot" (my group's recommendation) - meaning that the accelerometer's operation is not permitted to occur "during USB initialization!"    Again - we find no (reasonable) justification for continuing accelerometer measurements while "Connected to the PC!"    The simple presence of the SD Card strongly suggests that your Acquisition Board was intended to operate "Stand-Alone!" (FREE from the PC - while acquiring sensor data!)

    andres_dalmati said:
    despite its added complexity - "uDMA continues" - that's surely, "Premature Optimization" - and may invite issues

    You added the µDMA operation to (hopefully) speed the data transfer process.  (thus optimize!)   Yet - you earlier admitted to being (very) new to the µDMA - & you realize that its "Set-Up, configuration & usage" is complex - and may (by itself) cause or contribute to program issues!    This is why (any) added complexity should be AVOIDED during the early design/development process. 

    Lest you - or others - believe that I am being "overly harsh" upon µDMA - a frustrated poster here (2 days ago) noted "µDMA's Failure!"   (I could not ... make this stuff up! Evidence arrives thru this forum door DAILY - many users are "over-challenged" by (the devil) µDMA!)    Should not "Caveat Programmator" - "Let the programmer beware" flag rise?    (UCLA law provided the Latin.)

    "When i run the code without configuring dma it works perfectly fine!."
    https://e2e.ti.com/support/microcontrollers/other/f/908/t/892221

     Perfect the basics - confirm (proper) operation - and "Log the performance (actually) achieved."    Only then (when the "too early" (premature) stage has passed (i.e. your system IS working) - should you add the µDMA capability.   

    In this manner (really alone in this manner) you can then compare performance - (both) with & without µDMA - and see if the added code, & development time/effort proved "worthwhile!  (in the case of the (so small) SPI buffer - we believe µDMA's "gain" to be marginal - if any!   Such was reported here by the vendor!)

  • Hello Andres,

    Your USB initialization sequence is very poor. A lot of things are out of order. Perhaps what is happening is that when the accelerometer interrupt occurs, the system is given too much time to try and process an out of order setting and that triggers an issue. 

    If you hit a FaultISR - this is almost certainly the cause.

    Your order should:

    1) Enable peripherals in System Control (SysCtl calls)

    2) Enable GPIO pins

    3) Configure USB parameters

    4) Call USBDMSCInit

    The IntRegister would usually be done between either 3 and 4. You could do it earlier though, but configuring parameters -> setup ISR -> enable the peripheral is the typical order and USBDMSCInit is basically the USB equivalent to a call like SSIEnable.

    See if updating the USB configuration sequence resolves this issue.

  • Hi cb1,

    Thank you very much for the answers and advice, they were really helpful. I find very useful to have another perspective.

    Hi Ralph,

    This is my (pseudo) code, is very poor my initialization?

    int main(void)
    
    {
        // Se setea el clock del TM4C -> Clock 66.6 Mhz: 400/2  /3
        ROM_SysCtlClockSet(SYSCTL_SYSDIV_3 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
    	SysCtlDelay(10);	
    
    
    	//**************************************************************************
    	//**************************INIT_SSI***************************************
    	//**************************************************************************
    
    	SysCtlPeripheralDisable(SYSCTL_PERIPH_SSI3);
    
        // Se habilita el pin de CLK (pin0) como GPIO y se simula un clock
        // manualmente para salir de cualquier estado no deseado.
        SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    
        // SysCtlPeripheralEnable tarda 5 ciclos de clock en habilitar el periferico.
        SysCtlDelay(2);
    
        GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE,GPIO_PIN_0);
    
        for (i=0;i<15;i++)
        {
            GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_0, GPIO_PIN_0);
            // SysCtlDelay((SysCtlClockGet() / (1000 * 3)));
            GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_0, 0);
            // SysCtlDelay((SysCtlClockGet() / (1000 * 3)));
        }
    
        //
        // The SSI3 peripheral must be enabled for use.
        //
    
        SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);
    
        //
        //Configure the pin muxing for SSI3 functions on port D0, D1, D2, and D3.
        //
    
        GPIOPinConfigure(GPIO_PD0_SSI3CLK);
        GPIOPinConfigure(GPIO_PD1_SSI3FSS);
        GPIOPinConfigure(GPIO_PD2_SSI3RX);
        GPIOPinConfigure(GPIO_PD3_SSI3TX);
    
        //
        // Configure the GPIO settings for the SSI pins.  This function also gives
        // control of these pins to the SSI hardware.
        //
    
        GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3);
    
        //
        // Configure and enable the SSI port for SPI master mode.  Use SSI3,
        // system clock supply, idle clock level low and active low clock in
        // freescale SPI mode, master mode, 1MHz SSI frequency, and 8-bit data.
        // For SPI mode, you can set the polarity of the SSI clock when the SSI
        // unit is idle.  You can also configure what clock edge you want to
        // capture data on.  Please reference the datasheet for more information on
        // the different SPI modes.
        //
    
        SSIConfigSetExpClk(SSI3_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_3, SSI_MODE_MASTER, 1000000, 16);
    
        //
        // Enable the SSI3 module.
        //
        SSIEnable(SSI3_BASE);
    
        //
        // Read any residual data from the SSI port.  This makes sure the receive
        // FIFOs are empty, so we don't read any unwanted junk.  This is done here
        // because the SPI SSI mode is full-duplex, which allows you to send and
        // receive at the same time.  The SSIDataGetNonBlocking function returns
        // "true" when data was returned, and "false" when no data was returned.
        // The "non-blocking" function checks if there is any data in the receive
        // FIFO and does not "hang" if there isn't.
        //
        while(SSIDataGetNonBlocking(SSI3_BASE, &pui32Data))
        {
        }
    	
    	//**************************************************************************
    	//**************************INIT_ACC***************************************
    	//**************************************************************************
    	
    	// ******************* ACCEL SETUP  ********************************
    	H3LIS331DL_setup();
    	
        // ******************* ACCEL PIN INITIALIZATION  ********************************
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
    
        // SysCtlPeripheralEnable tarda 5 ciclos de clock en habilitar el periferico.
        ROM_SysCtlDelay(2);
    
        // This function provides the proper configuration for the pin(s).
        // The pin(s) are specified using a bit-packed byte, where each bit that is
        // set identifies the pin to be accessed, and where bit 0 of the byte
        // represents GPIO port pin 0, bit 1 represents GPIO port pin 1, and so on.
        // ATENCION!!! Esta función llama a:
        // - GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);  Make the pin(s) be inputs.
        // - GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);
        // Set the pad(s) for standard push-pull operation.
        ROM_GPIOPinTypeGPIOInput(GPIO_PORTE_BASE, GPIO_PIN_5);
    	
    	//**************************************************************************
    	//**************************INIT_SD_CARD***************************************
    	//**************************************************************************
        SDCARD_Init ();
    	
    	//**************************************************************************
    	//**************************INIT_USB***************************************
    	//**************************************************************************	
    	
    	//
        // Initialize the state to idle.
        //
        g_eMSCState = MSC_DEV_DISCONNECTED;
    
    
    	//
    	// Configure and enable uDMA
    	//
    	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
    	ROM_SysCtlDelay(10);
    	ROM_uDMAControlBaseSet(&sDMAControlTable[0]);
    	ROM_uDMAEnable();
    
        //
        // Enable Peripheral Clocks
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
        ROM_SysCtlUSBPLLEnable();
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
        ROM_SysCtlDelay(10);
    
        //
        // Enable pin PD5 for USB0 USB0DP
        //
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_5);
    
        //
        // Enable pin PD4 for USB0 USB0DM
        //
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_4);
    	
    	//
    	// Set the USB stack mode to Device mode without VBUS monitoring.
    	//
    	USBStackModeSet(0, eUSBModeForceDevice, 0);
    
    	//
    	// Pass our device information to the USB library and place the device
    	// on the bus.
    	//
    	USBDMSCInit(0, (tUSBDMSCDevice*)&g_sMSCDevice);
    
    	// Register USB interrupt handler
        USBIntRegister(USB0_BASE, USB0DeviceIntHandler_spilba);
    	
    	//**************************************************************************
    	//**************************INIT_INTERRUPTS***************************************
    	//**************************************************************************    
    	
    	// ******************* ACCEL INTERRUPT PIN INITIALIZATION  ********************************
        GPIOIntClear(GPIO_PORTE_BASE, GPIO_PIN_5);
    
        //  This function ensures that the interrupt handler specified by pfnIntHandler
        // is called when an interrupt is detected from the selected
        // GPIO port.  This function also enables the corresponding GPIO interrupt
        // in the interrupt controller; individual pin interrupts and interrupt
        // sources must be enabled with GPIOIntEnable().
        // Como se explica, se llama a:
        // -  ui32Int = _UARTIntNumberGet(ui32Base) to determine the interrupt number
        // based on the UART port.
        // -  IntRegister(ui32Int, pfnHandler) to register the interrupt handler.
        // -  IntEnable(ui32Int) to Enable the UART interrupt.No queda claro, pero
        // me parece que esta funcion habilita todas las interrupciones. Lo supongo
        // por este comentario que tiene: "Enable the general interrupt."
        GPIOIntRegister (GPIO_PORTE_BASE, ACCEL_Int_Handler);
        ROM_GPIOIntTypeSet  (GPIO_PORTE_BASE, GPIO_PIN_5, GPIO_HIGH_LEVEL);
        GPIOIntEnable   (GPIO_PORTE_BASE, GPIO_PIN_5);
    	
    	
    	// ******************* INTERRUPT PRIORITY  ********************************
    	// USB
        ROM_IntPrioritySet(INT_USB0, 0x20);
    	// ACCEL
        ROM_IntPrioritySet(INT_GPIOE, 0x80);
    	
    	ROM_IntMasterEnable();
    	
    	while (1)
        {
    		
    	}
    	
    }
    

    Thanks in advance.

    Andrés

  • Hello Andres,

    That looks a lot better than what you showed here: 

    Have you been able to test with this newly posted code?

  • Hi ralph,

    The code was always like that.

    Thanks in advance

  • Following your advice, I disable the accelerometer interrupt, and the PC can mount the SD. I also add the callback function, USBDMSCEventCallback, to initialization structure, g_sMSCDevice. Variables have the same name as in the example.

    But I don't understand why it doesn't change the variable g_eMSCState to MSC_DEV_DISCONNECTED, when I disconnect the USB. It remains at MSC_DEV_READ or MSC_DEV_WRITE.

    If I don't disable the interrupt, when I connect the USB, g_eMSCState remains at MSC_DEV_IDLE state.

    Thanks

    Andrés

  • Hello Andres,

    Understood that your setup process was correct then, for future reference, keep in mind that order of functions do matter to us when you are posting code. 

    andres_dalmati said:
    But I don't understand why it doesn't change the variable g_eMSCState to MSC_DEV_DISCONNECTED, when I disconnect the USB. It remains at MSC_DEV_READ or MSC_DEV_WRITE.

    The definition for MSC_DEV_DISCONNECTED states:

    //! \note In device mode, the USB_EVENT_DISCONNECTED will not be reported if
    //! the MCU's PB1/USB0VBUS pin is connected to a fixed +5 Volts rather than
    //! directly to the VBUS pin on the USB connector.

    As you are in eUSBModeForceDevice mode, the VBUS pin would not be monitored.

    One more question regarding the interrupt piece with the SD mounting. Are you mounting the SD right on startup (i.e. it is plugged in when you run), or are you trying to mount the SD card after code is executing and the program is already in the while(1) loop?

  • Hi Ralph,

    Thank you very much for your answer.

    SD is plugged before turning on the device.

    Thanks in advance

    Andrés

  • I could connect VBUS 's connector to USB0VBUS pin (my pcb allows it) and then change to eUSBModeDevice.
    As USB Library user's guide says "If the application needs to receive disconnect events it uses the eUSBModeDevice setting and must connect the VBUS pin to the USB connector and leave the ID pin unconnected."

  • Hello Andres,

    I did some more digging through our SD Card examples, and I found the following code in the 123G example for msc with SD cards:

        //
        // Determine whether or not an SDCard is installed.  If not, print a
        // warning and have the user install one and restart.
        //
        ui32Retcode = disk_initialize(0);

    What is key to note here is the comment about needing to boot with the SD card in - the reason I bring this is up is the following comment on the second example which is for the 129X:

        //
        // Initialize the SD card, if present.  This prevents it from interfering
        // with accesses to the SPI flash.
        //
        disk_initialize(0);

    To me, these two states imply that the SD Card mounting is a more sensitive application. All this indicates that the SD Card mounting should be done before enabling the accelerometer.

    One other question here, where does USB0DeviceIntHandler_spilba come from? I don't believe we have that in TivaWare. The TivaWare USB handler is USB0DeviceIntHandler and that is defined in usbdhandler.c. Did you adjust that definition? Could potentially be another issue, but right now it sounds like the SD card mounting process can't be interrupted.

  • Hello Ralph,

    This is my USB Handler interrupt:

    void USB0DeviceIntHandler_spilba(void)
    {
        ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_PIN_3);
    
        #warning
        GPIOIntDisable   (GPIO_PORTE_BASE, GPIO_PIN_5);
    
        USB0DeviceIntHandler();
    
        ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0);
    }


    I put ROM_GPIOPinWrite (up/down lines) into handler interrupt routines to see them with logic analyzer, and GPIOIntDisable to disable the acc interrupt.

    The SD Card mounting works OK on my application, I can log/write without any problem. Anyway in the pseudo code that I wrote previously, I had enabled the interrupts after mounting the SD in the end of the init application, BEFORE while (1).

    Though it would be better if I connect VBUS 's signal from the USB connector to USB0VBUS pin (and my pcb allows it) and then change to eUSBModeDevice as USB Library user's guide says "If the application needs to receive disconnect events it uses the eUSBModeDevice setting and must connect the VBUS pin to the USB connector and leave the ID pin unconnected." As the same pin is also connected to the corresponding pin in a BQ25890 should I pay special attention to any other "side  effect" ?

    Thanks in advance

  • Hello Andres,

    Okay understood on the USB interrupt change - makes sense now that you presented the API like that. Thanks.

    andres_dalmati said:
    As the same pin is also connected to the corresponding pin in a BQ25890 should I pay special attention to any other "side  effect" ?

    Where is VBUS being sourced from for the BQ25890, and how is the SD card being powered? The concern would be if any voltage sources might conflict. The TM4C VBUS pin does not provide 5V so it would not be a source of conflict. As long as the SD card is the same, then that should be fine.

  • Hi,

    I have another doubt.

    How can I improve the USB data transfer speed?

    I can download with a  ~330kb/s.

    Supposedly the microprocessor has USB 2.0, but this velocity does not correspond with that.

    Thanks in advance.

    Andrés 

  • Hello Andres,

    Are you expecting USB High Speed or USB Full Speed?

    The USB 2.0 specs for the device are for Full and Low Speed only:

    The TM4C123GH6PM microcontroller supports three configurations in USB 2.0 full and low speed:
    USB Device, USB Host, and USB On-The-Go (negotiated on-the-go as host or device when
    connected to other USB-enabled systems).
    The USB module has the following features:
    ■ Complies with USB-IF (Implementer's Forum) certification standards
    ■ USB 2.0 full-speed (12 Mbps) and low-speed (1.5 Mbps) operation with integrated PHY

  • Hi,

    I'm expecting at least full-speed

    Andrés

  • Hello Andres,

    Sorry for the delay, we were doing some testing on our end to provide performance numbers.

    How is your device setup? What USB mode are using and how you are transmitting data and measuring throughput?

    One test we did is with a Serial COM port that was limited to only 1kByte transfer total and with that we were about to see 8.9Mb/s or 1.1125 MB/s. Note that expected max bandwidth for 64 byte packet interrupt transfers is 1.216 MB/s, so we are very close to that mark with a properly setup system.