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.

debug active project : problem

Other Parts Discussed in Thread: MSP430F135

avi

i am trying to do "debug active project"  to my   program and i get this  message  :   

MSP430: Trouble Writing Memory Block at 0x200 on Page 0 of Length 0x3cc: Could not write device memory

Cannot write to target

i use microcontroller MSP430F135  which has a RAM  512 byts (address 0x200 to 0x3FF = 0x1FF==512 byts . and in the message  as you can see 0x3FF == 912 byts .how can i solve this problam ?     probably  something changed  i the configuration .

 

Thanks in advance for your help

avi . 

  • I do not know why you try to load your program to 0x200. As you know, for F135, 0x200 to 0x3FF are RAM. Normally, you try to put your program in Flash, so that once your program is loaded, it will stay there and will not disappear when you turn off the power. As a consequence, most development system will only try to load code to Flash and will respond with an error msg otherwise.

    What development system are you using? Did you tell it to put your code in 0x200?

  • The toolchain is not built to writ ecode into ram. The processor expects the start address of the program in 0xfffe, and if you have to writ eit there, you can as well put the whole program in flash. So it won't be erased on power-down.

    You can, of course, write code that copies itself to ram after start. Simply tell the compiler to put this code into initialized variables segment. The C startup code will do the copying on power-up/after a reset.

    The JTAG interface as well as the BSL supports loading code directly into ram (so-called funclets). In fact the flash write through JTAG is done by a funclet that is written to ram with the data to write to flash, and then executed there. Piece by piece. But the high-level code upload funcitons don't expect the target address to be in ram. They will try to flash the code to ram (which obviously will fail).

     

    But even if this would work, you will have an even bigger problem: the 135 has 512 bytes ram and your code is much bigger than that. So unless you find a way to put 16 bits into one byte, you're hosed. Make your program shorter, or put it in flash (where it usually belongs anyway)

  • Since you can copy code from flash to ram and run it in RAM, ideally you can download the code to ram and debug the code in ram. if the code that run in RAM is complicated and need c souce code level debugging.

    I believe IAR can do that.

    of course, in most cases, you can debug the code in flash and generate the code for RAM by changing the linker file(*.cmd).

    BUT in some cases, Code run ok in FLASH doesn't mean it will run ok in RAM. for example, programming system flash from flash is different form programming system flash from RAM.

    so ideally if you need run code in RAM, debug/test the code in RAM.

    EDIT:

    My apology, I tried the CCS 4, if you set up the link file(*.cmd) properly, you can load code to flash and run it from RAM and debug it easily. the compiler will look after the linker, souce code debug very well. I did the code that run from ram a couple years ago and have to set up manually. but if the code run from RAM is stored in external memory, you have to do it in the old way and debug it with the way I mentioned above. for example, in some firmware upgrade method, new Firmware and bootloader are loaded in the external flash,  when upgrading main firmware, bootloader is copied from external flash to RAM and program the system flash, which can save a little bit code space.

     

    Yong

**Attention** This is a public forum