TUSB3200 external MCU firmware support

Jose - the main engineer supporting this device is out of the office next week.  It will probably be early/mid the following week (~Sept. 27-28) before he'll be able to review your query.  -Lester

Hi, Lester.

The issue was present until I masked SOF interrupt on TUSB3200. Once done that, everything looks work fine, including TUSB3200 interrupts.

Now, I can go on working in control transfers and enumeration process. By now there is no need of using SOF...I will use it with codecs for audio streaming, but I must enumerate the device first...

SOF occurs every 1 ms, so it doesn't mean much load for cpu, but it makes the system crash :(

Then, I will wait for a few days for that support.

Thanks

Jose,

SOF is used for ACG loop tuning, to tweak the codec clocks.  If you are not using synchronous isochronous transfers, you probably don't need SOFs (actually, all samples that I have currently _do_ use synchronous isochronous transfers, so I can't be positive that this statement is true).  If SOF interrupt processing kills operation, I suggest that you follow through that code path to isolate the offending code - but it works here for me.

Frank

Jose,

What does the external MCU _do_ with regard to the TUSB3200A?  Most 3200 systems that I've seen use the 3200 to do everything (e.g., initialize codecs, send codecs mute/unmute as appropriate, send volume commands to the codec, send sample rate commands to the codec).  If you're using the 430 to do these things, you need to remove some of the capabilities exposed in the Audio Class descriptors, and/or establish some kind of communications link to the 430 to effect similar behavior.

Regards,

Frank

Hi, Frank.

The device already enumerated.

By now, I'm working on midi communications.

Maybe in a few days I'll start to work on audio codecs hardware design and their firmware support. So, I don't know at this moment if I should use synchronous or asynchronous isochronous transfers for audio streaming. I have to read a little more to choose between that two ways.

If I enable SOF, the only thing I do when SOF occurrs is clearing the VECINT register...there is no more code. But when SOF enabled, the device doesn't enumerate.

MSP430 doesn't do nothing related to audio streaming. It just initializes STC registers (DMA, ACG, audio streaming ENDPOINTS...) and STC will do all work, managing all audio transfers and controlling audio codecs through C-port.

MSP430 just handles midi transfers...I've added a MIDI STREAMING interface (with two bulk endpoints) to descriptors and it's working

Jose,

How does the MSP430 initialize STC registers?  Those registers are implemented in the TUSB3200A 8052's address space, to which an external controller has no access (unless you're operating the TUSB3200A in 'external' mode - but that's designed to be used with an external 8052 - in which case the external 8052 'runs' the application).

Sorry, we get queries from folks with a lot of different backgrounds/expectations, and don't mean to offend if I'm stating the obvious.

Regards,

Frank

Don't worry about it, maybe I didn't explain right.

Yep, I'm operating the TUSB in external mode, with MSP430 as external mcu.

MSP430 code is based on TUSB firmware kit code... I mean, I studied TUSB sample code and I translated into MSP430 IAR.

With this, I got the device enumerate, and midi transfers are working (midi streaming bulk endpoints are entirely handled by external MCU, including data buffers, in both directions IN and OUT)

Jose,

So, you enable SOF interrupts via the SOF bit in USBIMSK, and get a SOF interrupt 14h via VECINT.  You then write a value to VECINT to arm the 3200 for the next interrupt indication. 

Presumably the 430 uses the MCUINT0/ to generate an interrupt on the 430 (sorry, I'm not familiar with the 430). 

Are you successfully using interrupts via MCUINT0/ for other interrupt sources(e.g., you're successfully using the interrupt mechanism for control transfers), so it's only a SOF problem, not a generic interrupt problem)?  That is, you're successfully returning from interrupt on the 430.

Does the 430 continue to get SOF interrupts after that first one?

Actually, I'd be surprised if the USB host would enable the TUSB3200 if the host didn't 'see' valid descriptors.

I've been working with this device for over a year now, and I can't remember anybody using external mode for anything other than working with an emulator.  You can't take any advantage of the internal ROM, for example.

Regards,

Frank

Hi again, Frank.

Sorry for these days with no response.

I answer each question you made:

So, you enable SOF interrupts via the SOF bit in USBIMSK, and get a SOF interrupt 14h via VECINT.  You then write a value to VECINT to arm the 3200 for the next interrupt indication.

That's it.

Presumably the 430 uses the MCUINT0/ to generate an interrupt on the 430 (sorry, I'm not familiar with the 430).

Correct.
I use MSP430 P1.7 pin wired to TUSB3200 /MCUINT0 pin for external INT on the 430.

Are you successfully using interrupts via MCUINT0/ for other interrupt sources(e.g., you're successfully using the interrupt mechanism for control transfers), so it's only a SOF problem, not a generic interrupt problem)?  That is, you're successfully returning from interrupt on the 430.

Yes.

All other interrupts work sucesfully. With SOF disabled, de device enumerates and MIDI STREAMING interface works perfectly (I added this interface modifying sample code descriptors and adding some functions to handle midi transfers through one bulk endpoint).

Does the 430 continue to get SOF interrupts after that first one?

Maybe here we've got the problem...

Before first setup transaction (GET_DESCRIPTOR request), I watch through my debug tool that 45 SOF events occur, but I just count 42 SOF interrupts on the MCU....

I don't know why that happens...

Even with SOF int enabled, the first SETUP TRANSACTION interrupt occurs, but no more...well, one more SOF interrupt happens after that SETUP interrupt, but after this, no more interrupts are produced.

If I disable SOF during execution, interrupts work properly again.

Regards

Jose,

Here's one possibility (it may not be the solution, but someplace to start): 

Hypothesis:  You have configured the MSP430 for edge-triggered interrupts, and you are returning from the interrupt handler without ensuring that MCUINT0/ has de-asserted, so you never see a subsequent edge.  This could possibly happen if the interrupt mechanism gets two interrupts close-together-in-time. 

Both the sample application for the TUSB3200 EVM and the sample application for the TUSB3200 EVM2 set IT0 = 0 (i.e., they both use level-triggered interrupts).

You can use edge-triggered interrupts if you loop in the ISR until IVEC == 0x24, or use level-triggered interrupts.

If this doesn't help, would you please recreate your test case and once locked-up, look at the level on MCUINT0/ and see if it's high or low.

Hope this helps,

Frank

Good news.

I've used edge-triggered interrupt on MSP430 and looped ISR:

#pragma vector = PORT1_VECTOR
__interrupt void ext_int (void)
{ 
  if(P1IFG & BIT7) 
  {
    P1IFG &= ~BIT7;
    do
    { 
      atiende_stc();                                                              // TUSB3200 interrupt handler
     }while(lee_stc(STC_VECINT) != VEC_NOINT);    // Loop while VECINT != 0x24
  }
}

Now, de device enumerates with SOF enabled !!!

But there are still problems, due to ISR mechanism too, I think

With SOF enabled, midi transfers don't work properly...

I measured /MCUINT0 signal and it shows a 1 Khz signal...that's correct...SOF interrupt occurs each 1 ms, but now, midi is affected :(

Jose,

That's not a lot to go on, but you might want to be using the 'volatile' keyword.

And, I'm not familiar with P1IFG, but should that be inside the loop?

Frank

That's not a lot to go on, but you might want to be using the 'volatile' keyword

'volatile' for what?

for interrupt routine?

And, I'm not familiar with P1IFG, but should that be inside the loop?

Done and working.

The problem with MIDI looked to be in other place...It wasn't due to SOF

I were using a flag which was reset after initiating a transfer through MIDI IN endpoint, and set on completion of that transfer. I made this for ensure not to write the endpoint buffer with new data until last data was sent to host by TUSB3200 usb logic, always waiting for flag set before writing the buffer.

But, for any reason, this made sometimes the system locked.

I supressed that flag checking and now it looks to be working properly, with no data lost or corrupted, I think...

By now...SOF enabled, device enumerated, midi in working, midi out working...

Is time for audio hardware design.

Jose

Jose,

> 'volatile' for what?

Depending upon how you declare the variable, for any variable updated at ISR level that is used at non-ISR level - makes sure that optimizations don't optimize-out the actual read-from / write-to the variable.

You might want to take a look at your compiler documentation for the 'volatile' keyword;  its use might not be necessary in your situation. 

Regards,

Frank

Ok. I'll do it.

Thanks a lot, Frank

Regards