Problem with SR flags set using CMP instruction

Jon Clark said:

... int is 0x9010. ...

Do you mean the contents or the address?

Sorry. I mean that the contents of int are 0x9010. I also realize that if I were treating them as signed numbers than 0x9010 wouldn't be larger as it would be negative. But even so, the bits set in the SR don't make sense then either.

That is very strange. Which MSP430 are you using? Could you show me the code memory dump near and include the CMP instruction, and the data memory dump near and include "int"?

Wow! thanks for the help at this hour. I'm using the FR5739. I'm away from that computer and on another right now though. I'll be glad to share that sometime tomorrow when I'm back on that machine. It was odd to me that 0x9010 + 0x9E57(not.src+1) doesn't set an overflow or a carry bit.

CMP is a SUB without its result written.

SUB.W 25001 from 36880 = 11879 (it did not underflow)

11879 = 0010111001100111

Bit 15 is not set so N = 0

But it did go past from a value above a 32768 to below it, so V=1
This is only used incase you are treating the values as signed.
C flag = 1 (kind of reversed as 1= no underflow,0=underflow (rolled past zero))

Now you can use:
JNC/JLO Jump if no carry {no branch in your case}

JC/JHS Jump if carry (unsigned) {branch in your case}

JL Jump if less, signed jump if (N .xor. V)=1 {true in your case, so branch}

Just because they are referred to as Negative and Arithmetic overflow flags, Does not mean you can not use them for
non-signed value tricks. Maybe you have a loop that goes from 150 to 128?, checking N flag will do that.

You know, I think I'm using an equ there. so something like:

max equ 25001

mov.w #0x9010,&int

cmp.w #max,&int

I'm reaching now, but could cause any sort of problem?

It could be that you use a ; my comment after the define and complier get the whole line.
If there are any comments use // or */

I speculate that Jon has mistaken 9010 as 0x9010.

Oh, no. For all the trouble this has been giving me, I've already checked that. I think I may be crossing a word boundary. I think the low byte of &int may be on an odd address making a .W instruction grab a byte off something else entirely.

Jon Clark said:

I think the low byte of &int may be on an odd address making a .W instruction grab a byte off something else entirely.

You think? Why not look at the address in either the symbol map or in the debugger and *know*.

Some of the MSP430s, including FR57xx, will quietly ignore BIT0 of the address in such situations.

Jon Clark said:

I think the low byte of &int may be on an odd address

The segment should have an alignment setting that ensures that any word-sized symbol is word-aligned. Of course it could be that int is byte-sized and ends up at an odd address. However, then the previous mov.w would also move the word value to the wrong address, so it would be consistently wrong :)

Well, int could point to a register which returns something different than written. (like P1IN)

BTW: Tony is right, in a #define you must not use assembly style comments.The precompiler will only strip C style comments and do a full text replacement on the rest. But it is unlikely that you get wrong code and no assembler error then.

And OCY, all .W instructions (or .A) on all MSPs will silently ignore the LSB of the address.

Brain Boorman said:

You think? Why not look at the address in either the symbol map or in the debugger and *know*.

Because I was sitting in a hotel room with no access to my code or the IDE. Yes it was a word boundary problem. EVEN fixed it.