How to address (and write to) flash locations greater than 0xFFFF

F2618 uses MSP430X cup. PC, SP, SR, and R4..R15 are all 20-bit wide.

Thank you very much old_cow_yellow and aBUGSworstnightmare for your help.

My issue is resolved and am now able to address the locations above 0xffff.

rgds,

Kaushik

Dear Kaushik: I am using MSP430F6438 and have similar problem as how to address and write to flash locations beyond 0xFFFF? Can you show me explicitly how to write it? 

thanks 

Sunny

You should read the chapter about the CPU core in the users guide. It describes all this. When using a compiler, the compiler should handle this. You might need to tell it to do so, by e.g. configuring your project to use large data model. Be warned that using 20 bit addressing for data significantly increases code space and execution times (20/32 bit register saves instead of 16bit, 32bit pointers instead of 16 bit etc.)

Dear Jens-Michael:

        Thank you very much for your answer. Please let me describe my questions more in details . I’m using MSP430F6438 target board which has 4 bank main code memory. I choose bank2 which starts with 028000h address, because I estimate my code size will much less than 128KB and shall be inside the bank0 and bank1. So, my flash test code as below:

unsigned int *pRaw, i;

         pRaw = (unsigned int*) 0x28000;

          FCTL3 = FWKEY;                            // Clear Lock bit

  FCTL1 = FWKEY+WRT;                                 for(i=0;i<256;i++)

          {

            *pRaw++ = i;          }

          FCTL1 = FWKEY;                            // Clear WRT bit

          FCTL3 = FWKEY+LOCK;                       // Set LOCK bit

But when I check with IAR debug mode, the value of *pRaw is not equal to the value of i. I use similar code for FG439, it works fine. I don’t know why it won’t work here. Please help me to solve this problem. Thanks again.

Best regards,

Sunny Hwang

The FG439 has a CPU core with 16 bit address bus. The F6438 has an extended core with 20 bit address bus. However, the standard instructions used are still 16 bit. A bit like the 8088 processor and the memory above 1MB which became available with the 286 and 386 processors and their protected and V86 mode instructions.

To access memory above 64k (0x0FFFF), the extended instructions of the 20 bit core need to be used.
On those processors, the defaul tco demode setting is 'large', so the compiler will automatically use the extended instructions for code (CALLA instead of CALL, RETA instead of RET). This gives slightly slower code and larger stack usage (32 bit isntead of 16 bit need to be stored for the return address) but allows code to be placed in full 1M address range. With this large code model, function pointers are 20(32)bit, but this is not a big problem, few people directly use function pointers in their code.

However, if you want to access data above 64k, things are different. If data pointers are 20(32)bit, then all push and pop operations need to use the extended instructions to save 20 bit register contents. Which makes the program significantly slower and bigger. Including ISRs, and significantly increases stack usage too. This is why large data model is not the default.

If you only need data access at some specific places (e.g. your flash write function), then you can stay with small data model and use the compiler provided intrinsic for high memory access, which take a 32bit address and a 16 bit value and write (or read). Like “__data20_write_short(addr, data)” (which basically does “MOVA addr, Rx ; MOVX.W src, 0(Rx)”

Dear Jens-Michael:

         Thanks for your help. I'll study that in more details, but looks like it's not easy for me. I'll use external EEPROM IC instead, just in case.

Really appreciate for your help.

Best Regards,

Sunny