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.

problem with macro for register access



Hello all,

I'm using CCS V5.5 and C/C++ compiler V4.2.4.

For my code I need to develop a little function for I2C access, but it is just for the example, an abstract below:

	HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW1) |= UCSWRST;                       // Enable SW reset
	HWREG16(EUSCI_B0_BASE + OFS_UCBxTBCNT) = byteCount;
	HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW1) &= ~UCSWRST;                     // Clear SW reset, resume operation
	HWREG16(EUSCI_B0_BASE + OFS_UCBxIE) = UCNACKIE;
	HWREG16(EUSCI_B0_BASE + OFS_UCBxIE) = UCTXIE0;                           // Enable TX ready interrupt
	HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW0) |= UCTR;			               // I2C TX
	HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW0) |= UCTXSTT;               // start condition

At the beginning, I wrote simply for example

	UCB0CTLW1 |= UCSWRST;                       // Enable SW reset

But I never had the interrupt (nor Start bit on I2C). I tried a formalism like this:

	HWREG16(UCB0CTLW1) |= UCSWRST;                       // Enable SW reset

Same problem, moreover the code generated in the last two cases was in extended mode (MSP430X) and may be two time heavier than my first example.
In the debugger all was OK, and I discovered that

	HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW0) |= UCTXSTT;               // start condition

works perfectly. If I change back this line and only this line, the interrupt failed again.

I have not really the time to investigate as I am really busy and I have a workaround, but do you have any clue about this? I gave a look on HWREG16() and SFR_16BIT(), I can understand that the generated assembly code is more heavier, but not why the code is not functional...

Best regards

  • Hello wilfrid,

    Are you using DriverLib in your project? UCB0CTLW1 |= UCSWRST; should work so long as SFR_16BIT(UCB0CTLW1); is properly initialized in your header file, but HWREG16(UCB0CTLW1) |= UCSWRST; should not. Can you provide a simple C code file that demonstrates the issue you are experiencing?

    Regards,
    Ryan
  • Hello Ryan,

    Sorry, I found a copy/paste error elsewhere who explain my difficulties and I myself caused the problem in seeking a solution.

    • UCB0CTLW0 |= UCTXSTT; is functional
    • HWREG16(UCB0CTLW0) |= UCTXSTT; failed.
    • HWREG16(EUSCI_B0_BASE + OFS_UCBxCTLW0) |= UCTXSTT; is functional also but generate lighter assembly code.

    I am not really use Driverlib, just some some simple function from TI library, to use HWREG16(), I manually include hw_regaccess.h
    In fact I start again a several years old project, I suppose I had start to use this formalism from some examples at the time, I don't remember.

    In fact, I have 2 questions:

    • Will the compiler lighten the code if I specify the small memory model? I let it empty for the moment, but it does not take into account I use a 16KB max FRAM µC.
    • If not, is there any drawbacks using the deprecated formalism?

    Thank you for all, best regards,

    Wilfrid

  • Please note that the HWREGxx macros want the address of the register as the parameter.

    When you write "HWREG16(UCB0CTLW0)", the code reads the register, treats the register's value as an address, and then accesses that address.
    You'd have to use "HWREG16(&UCB0CTLW0)" instead.

  • The memory model has no effect on code size (and your device cannot access a large memory space regardless), but optimization settings will.

    Use whichever format you prefer, just keep into account the difference between a register's value and address as explained by Clemens.

    Regards,
    Ryan
  • Thanks for all Ryan and Clemens,

    I thought the memory model implies code or memory to be restricted to 64k then the compiler do not need dedicated extended instruction. The optimization settings I tested change nothing to the compiler choice of extended instruction or not regarding these particular instructions, but I have no time to investigate more.

    Clemens you're right I should be mode careful HWREGXX() macro need an address ;)

    Best regards,

    Wilfrid

**Attention** This is a public forum