msp430F5510 trace buffer

Hi Bob,

That I understand, yes the MSPF5xx should support trace.

Please see this post and keep us informed whether it helps.  You will likely want to ensure that you have an up to date CCS version as well.

https://e2e.ti.com/support/development_tools/code_composer_studio/int-code_composer_studio/f/90/t/48695.aspx#173093

Best Regards,
Lisa

Thanks, Lisa.  I'll just have to tough it out, with maybe a small hope of trace coming about.

I can't express how grateful I am to be involved with my new project wherein I'm using TI parts.  TI was always good with engineering suport (especially the yellow books), but to have the help of an actual TI employee who is knowledgible in the field is outstanding.  I just finished a year spent learning the hard way why a PIC is considered a hobbyist processor, and the contrast is incredible.

Best regards,

Bob White

Hi Bob,

no problem at all and thanks for the kind words. 

Once again my appologies for the confusing initial response.  (Trace did previously actually have some very limited support no longer there).  

All the best with development.

Best Regards,
Lisa

I think that the MSP430F5529 does support trace. True? If so, how do I use it?

Kent

Hi Kent,

Unfortunately I do not believe trace is currently supported on the MSP at all.

Best Regards,
Lisa

Lisa

The MSP430F5529 has an EEM module. SLAU208J page 940 talks of "Storage of internal bus and control signals using an integrated trace buffer (device dependent)". How  do I used that and what does it do?

Kent

Hi Kent,

these are features we are working on opening up going forward  :  )

Best Regards,
Lisa

Lisa

I have a problem where registers are being changed for no apparent reason when I am using the USB to transmit data.  Everything is fine if the USB is enumerated, but not when the USB is transmitting data. For example, a result is correctly sitting in the RESHI location. The following code is executed

    tmp=RESHI<<2;
    if(!((tmp==2628) || (tmp==26288))){
        _NOP();
    }

After the shift, tmp should be either 2628 or 26288, but it is not, about one in a hundred times, resulting in the _NOP() being executed. OK the rest of the time.

Any ideas about what is going on?

Kent

MSP430F5529, USB, multiplier interference

The USB software, specifically the interrupt service routine,  CdcToHostFromBuffer, alters the multiplier values without saving and restoring them. I have not figured out how. CdcToHostFromBuffer in UsbCdc.c is called by __interrupt VOID iUsbInterruptHandler(VOID) in UsbIst.c Here is what I know:

I am using the USB to output a lot of data.

I set and clear a test point before and after I load the multiplier (MPY and OP2) I also check to see if the product is correct. If not, I also set and clear the test point. Thus there are 2 pulses if the result is correct and 3 if not. I also set another test point at beginning of  CdcToHostFromBuffer and clear it at the end. The product is sent to a D2A converter. A 'Scope triggers when the converter output is outside to the correct range, ie when a wrong value is used. I then let the '5529 run. Occasionally the scope triggers with an out of range value. I then put  __disable_interrupt(); and  __enable_interrupt(); around the setting and reading of the multiplier. The scope never triggers.

I then replaced __disable_interrupt(); with usbietemp=USBIEPIE;  USBIEPIE=usbietemp & ~BIT2; before setting up the multiplier and __enable_interrupt();  with USBIEPIE=usbietemp; after. This stops the interrupt associated with CdcToHostFromBuffer only while the multiplier is setup and read and the '5529 still works well (the scope doesn't trigger). I comment out & ~BIT2 and it no longer works (the scope triggers). This convinces me that CdcToHostFromBuffer is doing something to the multiplier.

I haven't found the write to the multiplier though. Maybe there is a pointer error. It sure would be nice to be able to do a trace. When I set a breakpoint to trigger when the wrong product is read, I see that both MPY and OP2 are not the values they should be.

I'd love some ideas.

Kent