Compiler/MSP430FR5969: unable to write to HIFRAM (upper memory)

note: It occurred to me that a pointer to upper memory should require more than 16 bits because of the 20 bit addressing but replacing uint16_t with uint32_t changes nothing.

Hello,

Could you check the MPU register setting to see if the HIFRAM is writable?

Hi,

Have you added code to disable the watchdog before the CRT code initializes data and bss? Since you have a large program, the watchdog might fire before you reach main.

See this thread for an example: https://e2e.ti.com/support/tools/ccs/f/81/p/496916/1797071#1797071

(We're going to document this in the next version of the user guide since this a common problem)

The problems writing to HIFRAM are probably a separate issue as Winter pointed out.

Regards

I believe that the settings are correct. I tried two approaches and neither changed the results from my initial post. As the user guide states, the memory should be rwx accessible if the MPU is disabled:

To test this I added it to the device setup provided in the blink.c example from msp430-gcc:

int main(void) {
WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer

P1DIR |= 0x01;                                        // Set P1.0 to output direction
PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode


MPUCTL0 = MPUPW | 0x0;

.
.
.
<HIFRAM write operations>
.
.
.

As expected, gdb shows that the value is 0x9600 meaning that the MPU is disabled and the full memory should therefore be rwx accessible. Unfortunately this did not change anything. I then tried to enable the MPU and set write enable for all memory segments:

int main(void) {
WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer

P1DIR |= 0x01;                                        // Set P1.0 to output direction
PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode


MPUCTL0 = MPUPW;
MPUSAM = MPUSEG1WE | MPUSEG2WE | MPUSEG3WE;
MPUCTL0 = MPUPW | MPUENA;

.
.
.
<HIFRAM write operations>
.
.
.

Similarly, this did not change anything. What am I missing?

The first thing the main function does is disable the watchdog so that shouldn't be a problem in this case. In my reply to Winter I posted a more complete version of the main function so it should hopefully be more clear now.

Change  IDE, and try agagin.  I think it 's more like a IDE setting issue.  

Use IAR for MSP430 (Large Mode) or CCS.

EmbeddedMike said:

The first thing the main function does is disable the watchdog so that shouldn't be a problem in this case. In my reply to Winter I posted a more complete version of the main function so it should hopefully be more clear now.

#include <msp430.h>                                                                                     
#include <stdint.h>                                                                                     
                                                                                                        
int main(void) {                                                                                        
    WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer                                      
    PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode    
                                            // to activate previously configured port settings          
    *(volatile uint16_t *) (0x10000) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x10002) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x11000) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x11F00) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x11F02) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x12B00) = 0xFACE;                                                          
    *(volatile uint16_t *) (0x13FD2) = 0xFACE;                                                          
                                                                                                        
    P1DIR |= 0x01;                          // Set P1.0 to output direction                             
                                                                                                        
    for(;;) {                                                                                           
        volatile unsigned int i;            // volatile to prevent optimization                         
                                                                                                        
        P1OUT ^= 0x01;                      // Toggle P1.0 using exclusive-OR                           
                                                                                                        
        i = 10000;                          // SW Delay                                                 
        do i--;                                                                                         
        while(i != 0);                                                                                  
    }                                                                                                   
    return 0;                                                                                           
}                                                                                                       

(gdb) x 0x10000 
0x10000:        0xfaceface 
(gdb) x 0x11000 
0x11000:        0xffffface 
(gdb) x 0x11f00 
0x11f00:        0xfaceface 
(gdb) x 0x12b00 
0x12b00:        0xffffface 
(gdb) x 0x13fd2 
0x13fd2:        0xffffface

EmbeddedMike said:

note: It occurred to me that a pointer to upper memory should require more than 16 bits because of the 20 bit addressing but replacing uint16_t with uint32_t changes nothing.

Note that the way your FRAM write code behaves is actually like this:

*((volatile uint16_t *) (0x10000))= 0xFACE;

i.e. 0x10000 is the value of a pointer to a 16-bit volatile integer. No matter what you change uint16_t to, "(volatile uint16_t *)" is always a pointer so will be a 20-bit integer with -mlarge, and a 16-bit integer with -msmall.

But it is essential that uint16_t matches the size of the value on the RHS of the assignment, or at least matches what you expect to write.

For example (note we write to 0x10002 first):

*((volatile uint16_t *) (0x10002))= 0xFACE;
*((volatile uint16_t *) (0x10000))= 0xFACE;

(gdb) x 0x10000
0x10000:        0xfaceface

But if you change the type of the value the pointer points to, then the resulting writes to memory will be affected:

*((volatile uint32_t *) (0x10002))= 0xFACE;
*((volatile uint32_t *) (0x10000))= 0xFACE;

(gdb) x 0x10000
0x10000:        0x0000face

The second write actually told the compiler you want to write 0xFACE0000 to address 0x10000. So 0x10000 will contain "0xFACE", and 0x10002 will contain "0x0000".

Thanks for the feedback but if the settings are a problem then I'll have to fix my compiler flags. I transitioned my project away from CCS, so I now have a makefile that builds my project and then I use gdb to load, execute, and debug. I did some digging it seems that the compiler flag equivalent of the settings you highlighted are addressed here:

My build currently uses the "-mlarge" flag so based on my understanding, I should have access to the full memory range using 20-bit pointers.

I'm not familiar with GCC. But you can take a look at the disassembly, you'll find it's not a difficult work to locate the cause.

 *((volatile uint16_t *) (0x10000) ) = 0xFACE;  

MOVX.W     #0xFACE  ,&0x10000

___right    :)

if the disassembly looks like:

MOV.W   #0xFACE, &0x10000  （not extended instrcution,write /read address out of 64KB need extended instruction.)

it must  be    :(     failed. and it will lead you to see if it's a complier issue.

Stepping through the assembly instructions in gdb has been very helpful, thanks for the suggestion!

Glad to hear that. And thanks for sharing your findings.