Based on what I tried with your example yesterday, mspgcc generates the code as you've written it, but it probably doesn't do what you intended.
>From my experience, only the relatively small RAM section (and the really tiny information memory blocks) can be written with standard MSP430 instructions like this. I'm not aware of any existing MSP430 parts that have RAM above the 64KB boundary. Anything in high memory will be read-only: the flash memory requires an external JTAG programmer or the bootstrap loader special to be writable See http://focus.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=slau265j&docCategoryId=6&familyId=342 I don't know how the new FRAM parts work, but I expect they still require some sort of configuration to enable writes. Peter On Fri, Aug 5, 2011 at 5:57 AM, Alex Stefan <[email protected]> wrote: > Peter Bigot <bigotp <at> acm.org> writes: > >> >> On Thu, Aug 4, 2011 at 10:22 AM, Alexandru Stefan >> <alexandru.stefan <at> cloudbit.ro> wrote: >> > Hello, >> > >> > I am currently working on two inline routines to read and write >> > data to >> > addresses >64k. >> > >> > This is the 'write' routine: >> > >> > >> > static inline __attribute__((always_inline)) void >> > flash_write(uint32_t addr, >> > uint16_t val){ >> > >> > __asm__ __volatile__ ( >> > "dint \n" >> > "nop \n" >> > "pushx.a r15 \n" >> > "movx.a %[addr], r15 \n" >> > "movx %[val], @r15 \n" >> > "popx.a r15 \n" >> > "eint \n" >> > : >> > :[addr] "r"(addr), [val] "r"(val) >> > ); >> > } >> > >> > and this is the asm code it generates: >> > >> > static inline __attribute__((always_inline)) void >> > flash_write(uint32_t addr, >> > uint16_t val){ >> > >> > __asm__ __volatile__ ( >> > 315c: 2e 44 mov @r4, r14 >> > 315e: 1f 44 02 00 mov 2(r4), >> > r15 ;0x0002(r4) >> > 3162: 1d 44 04 00 mov 4(r4), >> > r13 ;0x0004(r4) >> > 3166: 32 c2 dint >> > 3168: 03 43 nop >> > 316a: 00 18 .word 0x1800; ???? >> > 316c: 4f 12 push.b r15 >> > 316e: 00 18 .word 0x1800; ???? >> > 3170: 4f 4e mov.b r14, r15 >> > 3172: 40 18 .word 0x1840; ???? >> > 3174: 8f 4d 00 00 mov r13, >> > 0(r15) ;0x0000(r15) >> > 3178: 00 18 .word 0x1800; ???? >> > 317a: 7f 41 pop.b r15 >> > 317c: 32 d2 eint >> >> 0: 32 c2 dint >> 2: 03 43 nop >> 4: 00 18 4f 12 pushx.a r15 >> 8: 00 18 4f 4e movx.a r14, r15 >> c: 40 18 8f 4d movx r13, 0(r15) ;0x00000(r15) >> 10: 00 00 >> 12: 00 18 7f 41 popx.a r15 >> 16: 32 d2 eint >> 18: 30 41 ret >> >> Your disassembler isn't up to date. >> >> Peter >> > >> > uint32_t address = 0x11110UL; >> > uint16_t val = 0x33; >> > >> > flash_write(address, val); >> > } >> > >> > The main question is why is used the simple MOV instruction >> > instead of the >> > extended version? >> > >> > Regards, >> > Alex >> > >> > >> > ---------------------------------------------------------------------------- > -- >> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> > The must-attend event for mobile developers. Connect with experts. >> > Get tools for creating Super Apps. See the latest technologies. >> > Sessions, hands-on labs, demos & much more. Register early & save! >> > http://p.sf.net/sfu/rim-blackberry-1 >> > _______________________________________________ >> > Mspgcc-users mailing list >> > Mspgcc-users <at> lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > >> >> ------------------------------------------------------------------------------ >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> The must-attend event for mobile developers. Connect with experts. >> Get tools for creating Super Apps. See the latest technologies. >> Sessions, hands-on labs, demos & much more. Register early & save! >> http://p.sf.net/sfu/rim-blackberry-1 >> > > Thanks for the reply. > > I have implemented some simple read/write routines (both for byte and > word operations) from >64k addresses and found some unusual problems: > 1) When using only byte operations with the variables located in RAM > (local to functions), everything worked ok. > 2) When writing first a value located in the flash (global static array) > and then values from RAM, the read/write routines didn't work as > expected. > 3) When alternating byte/word operations, some of them didn't work (the > read value was incorrect) > > I am just beginning working with assembly and, although I have a clear > idea of what I need to do, it's quite possible that I've made some > errors in the routines: > > static inline __attribute__((always_inline)) void > flash_write_byte(uint32_t addr, uint8_t val) > { > > __asm__ __volatile__ ( > "dint \n" > "nop \n" > "mova %[addr], r15 \n" > "movx %[val], @r15 \n" > "eint \n" > : > :[addr] "r"(addr), [val] "m"(val) > ); > } > static inline __attribute__((always_inline)) uint8_t > flash_read_byte(uint32_t addr) > { > > uint8_t result; > __asm__ __volatile__ ( > "dint \n" > "nop \n" > "mova %[addr], r15 \n" > "movx @r15, %[result] \n" > "eint \n" > :[result] "=m"(result) > :[addr] "r"(addr) > ); > return result; > } > > > static inline __attribute__((always_inline)) void > flash_write_word(uint32_t addr, uint16_t val) > { > > __asm__ __volatile__ ( > "dint \n" > "nop \n" > "mova %[addr], r15 \n" > "movx %[val], @r15 \n" > "eint \n" > : > :[addr] "r"(addr), [val] "r"(val) > ); > } > > static inline __attribute__((always_inline)) uint16_t > flash_read_word(uint32_t addr) > { > > uint16_t result; > __asm__ __volatile__ ( > "dint \n" > "nop \n" > "mova %[addr], r15 \n" > "movx @r15, %[result] \n" > "eint \n" > :[result] "=m"(result) > :[addr] "r"(addr) > ); > return result; > } > > > Thanks, > Alex > > > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
