Code composer and inline asm

sorry, I ment

#define

No wonder that the compiler uses an AND instruction and not a BIC instruction. Why shouldn't it? You tell it to do so. I tis beyond the capabilities of the compiler to see a reason why it should take the value you provide (~ADC_SPI_CS_1pin) XOR it with 0xff and use BIC when it can just do what you say: AND it with the value. Afer all the expression is a constant and calculated at compile-time. And why wasting code for something the compiler can do at compiler time.

Things could be different if the calculation of the constant couldn't be done at compiler time. Maybe because the bit value is a parameter of a function rathern than a constant. Then the compiler could determine that it is smaller to do a BIC instead of inverting the value with XOR and do an AND.

The OR operation, however, is just an alias for the BIS instruction. It makes no difference whether the compiler uses one or the other. Both result in the same binary code.

A LOT of MSP mnemonics are aliases, Such as the POP instruction which is actually a MOV @SP+,x instruction, or the DINT instruction which generates a BIC #GIE,SR opcode. or INCD, which is an ADD #2,x, which itself is rather an ADD @r2,x or so (using the constant generator feature of R2/R3). Check the family usrs guide. Many of the described mnemonics have an 'emulated instruction' entry listed in the description which described how the instruction is emulated through a different one of the same outcome.

So if you see the compiler generating a BIS instruction instead of an OR, when you look at the code in the debugger, it's rather that the debugger kannot see that the generated instruction was an OR originally.

For the handling of the ports, the digital outputs and whaever, it makes no difference how the port is addressed. If a BIT is set to I/O in the PxSEL register, it will be affected by a PxOUT write, if it is switched to module use with PxSEL, it won't. And reading and writing back bits from/to PxOUT won't affect the unchanged bits too.

So I don't think your problems are related to the generated instruction. There must be something else wrong with your code. Or maybe it is just that the active debugger interferes with your timing. Depending on the device and the debugger settings, the debugger won't/can't stop the clock sources when it stops the CPU for peeking into its state. Observation changes the things we observe. That's an universal rule. And in your case the changes might be significant.

I don't have informations about inline assembly under CCE or IAR, so if someone else could supply the information, I'd be interested too, even if I don't use them (I can provide informations about MSPGCC inline assembly, if required)
But I don't think that usign inline assembly  will help you there.

Thank you for your response.

After a weekend of playing around, I  stumbled into the correct syntax for the ASM command. asm("<tab>cmd<tab>pram,<tab>pram"); 

I was using space  characters  in place of the tab character between parameters and I had nothing in front of the mnemonic.  This is where having proper documentation would have saved me several hours

You are right about the "AND" instruction not being the problem. I was able to replace it with a bit clear & bit set commands and the system still does the same thing.

I've looked into the debugger as being the source of my woes, I have explored many of the options  under the debugger options and have unchecked all of the (stop) clock controls as  well as playing around with the "free run mode".  So far none of these options have made a difference.  I've also tried disconnecting the debugger and running the system as it normally would after a power cycle and this same problem exists.

I've also stopped the debugger at similar locations for both compilers and recorded the register contents for the port set up as well as the timer A3 and they are the same.

I am using a MSP430F2617.  At this stage my two theories of producing this fault are ...

option 1: the register map between the two compilers is not the same.  I've check the PORT addresses so far and they are the same so I'll look at the Timer's register next.

option 2: somehow the OUT bit of TACCTLx is being stepped on which would produce the results I'm seeing.  I am not using that featured in this program but who's to say the interpretation of some pointer is being handled the same way by the two different compilers.

any other  thoughts would be appreciated

thank you

Marty

I don't know whether really TAB is required. Usually, whitespaces are taken (any number of TABs or spaces).

But I remember that some other assemblers I used in th epast (not for MSP) required a leading whitespace or they took the first word as jump label.

I agree that proper documentation is vital. But usually, only the most common features and functions are well documented. Using mspgcc, even if doing so under windows, I have to deal with the linux world. There the key features are documented in big letters, but if it comes to the more special things, documentation fades away, often to a simple 'there is an option named x' and then nothing more. Not what exactly it does and what the side-effects are. Sometimes not even the parameters are listed. And if you're so lucky to get hold of the source code, you'll find 3 pages of GNU license information but not a single comment about what the code actually does.

It took me several hours too to find documentation about the (msp)gcc inline assembly syntax, and then it was a general one and did not cover the MSP specific implementation.

About your problem: I don't think the register map is faulty. Yes, soemtimes there are bugs in the header files, but for those often-used modules like ports and timers, these bugs should have been found and eliminated long ago. It is still possible that the documentation itself was faulty and therefore the include files have been built with this faulty information (I had this with the 54xx USCI module where two registers were swapped, now the doc has been corrected and so did the header files).

But it is more likely that your port initialisation code has a problem. To verify this, i'd need to take a look at it, at least at the parts that alter any Px or TAx register.

If properly initialized, setting a bit in P1OUT will only change this ones port pin value, and only if the corresponding bit in P1SEL is clear. The only exception is if the port pin is an input pin and pullup registers are enabled. But since you output the TACCR1 signal (at least that is what I believe to have figured out by your former posts), it should be output and therefore no pullups and no reaction. Also, setting a bit will only affect this pin (if configured), and not the other pins on the port.

So if you really set (1<<4) and not just 4, there should be no influence on P1.2, where TA1 is being put out.