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.

MSP430FR2355: Issues with the carry bit in MACS operations of HW multiplier MPY32

Part Number: MSP430FR2355


Hi

I found this issue, which is probably a misunderstanding of the family manual for MSP430FR2/FR4 family.

But, even after a lot of digging cannot seem to find out what is wrong.

It says in section 16.2.2 of the family manual under the MPY32 chapter that the carry bit (MPYC) in a MACS operation reflects the carry of the accumulation.

But, from my small test program I somehow can not manage to see that.

I do first a simple signed MPYS operation of -6 and 5 that gives a result of -30 as expected.

And for MPYS operations the carry bit should be set to the sign of the result, which it is. MPYC is 1 (set) in this case.

However, when following up with a MACS operation of -4 by -5, the multiplied result that is 20 should be added

to the previous result (-30) to give -10. A result that I get. But, to my surprise the carry bit (MPYC) is set in MPY32CTL0.

WHY?

Since I work with a 16x16 multiplication, the accumulation of the previous result with the new multiplication should be done in 32 bits.

The previous result is (-30, 0xFFFF FFE2) added to the the new multiplication (+20, 0x14) is indeed -10 (0xFFFF FFF6).

But, this sum does NOT overflow 32 bit (FFFF FFE2 + 0000 00014 = FFFF FFF6), so no carry should be set?

What am I mis-understanding here?

Note 1: I can indeed reproduce same effect when using full 32x32 bit multiplications.

Note 2: All my examples produce expected RESx registers and SUMEXT register, the ONLY issue is with

the MPYC bit in MACS operation. All other multiply operation types give a MPYC bit that matches the family manual description.

Here is the example program that I run and that gives at the last line (status = MPY32CTL0) a MPYC bit set to 1, when I expect 0!

// START SAMPLE CODE:

int main(void)
{
volatile unsigned int i, j, status;

WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

// some test multiplications
MPYS = 0xFFFA; // -6
OP2 = 0x5; // +5 => (-6)*(+5) = -30
__no_operation();
i = RESLO;
j = RESHI;
status = MPY32CTL0;
__no_operation();

MACS = 0xFFFC; // -4
OP2 = 0xFFFB; // -5 => (-4)*(-5) = +20 Total accumulation => -30 + 20 = -10
__no_operation();
i = RESLO;
j = RESHI;
status = MPY32CTL0;

}

// END SAMPLE CODE

Appreciate if someone can point out the problem here.

Sincerely Brown Bear

  • As I check, there is no code example for MPY32. However, if you use IQmath/Qmath it will automatically use this peripheral. Can you refer to that one?

  • Have you read the manual on MACS overflow at 16.2.2.1? Since your example didn't overflow then carry is going to be the same as the sign.

  • Hi! Thanks for the advice. I work on some arbitrary width math library and this IQmath could really be helpful in that implementation.

  • Thanks for helping out! I am not 100% sure were you are going, but what you say triggered the following thinking. I interpreted the last paragraph of 16.2.2.1 just as a statement of a fact that if there are overflows or underflows then the MPYC and SUMEXT bits are different (But, I was assuming MPYC still reflects an arithmetic CARRY bit out of the 32nd or 64th bit of the accumulation). But, if I am guessing at what you try to say, you say that in the case of underflow/overflow the MPYC on purpose is set to the different value of what SUMEXT is set to, just to signal that an underflow/overflow took place. Basically then the MPYC bit is no longer a pure CARRY bit, it is a combination of a carry and a signaling mechanism for underflow/overflow? Am I right in this interpretation of your answer? If that is the explanation, your answer resolves this issue. I will then do some more tests to check that out.

  • Hi! I then concluded after testing many other examples that this indeed is the correct interpretation. In MACS mode the carry bit (MPYC bit) has nothing to do with arithmetic carry at all! It just signals overflow/underflow situation. If SUMEXT and MPYC disagree it signals that underflow/overflow happened.

**Attention** This is a public forum