• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 768 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5358: Unable to write Flash memory

Kokila K
Prodigy 135 points

Part Number: MSP430F5358

Hi team,

In our design we are using MSP firmware upgradation via I2C using Custom Bootloader. In that flash memory of MSP is divided into Dowload partition, App partition and App manager partition. The binary is sent from Master to the MSP430 which configured as slave and copied in to the download partition. Further the CRC is checked from the master and copied data , on matching of the crc its copied into the APP partition and similarly the CRC is checked. On successfull CRC  matching the MCU goes for reboot which will loaded with the new firmware.

we are facing an issue in this, where the above mentioned steps is working fine when the image size is around 65Kb. when the image size exceeds, the copy from master to download area is fine and teh CRC is matching. but the copy from Dowload partition to APP partition is failing. This is happening only when the image size exceeds the 65kb, otherwise the copy is getting passed. what could be the reason behind this. Kindly help me here

Regards,

Kokila K

  • 0
    TI__Guru 56685 points

    Hello Kokila,

    I think your issue is the code you have done has only been compiled in "small memory" model. This uses the standard MSP430 instruction set only. You would need to compile in "large memory" model to use the extended instruction set to address memories larger than 64kB (20 bit addressing). 

    The other possibility is you may need to split your image up from a linker perspective if it's going to cross over the 64kB line. If you take a look at your linker file, you would typically see the FLASH area split up into FLASH (lower 64kB) and FLASH2 (>64kB). 

  • 0 in reply to Jace H
    Prodigy 135 points

    Hi Jace,

    Thanks for the reply. This is the current Flash partition of the flash memory.

    In the above partition, The bootloader will be in app manager and the image from master will be copied to the download partition. once the crc check matches, the same image is copied to the app partition. 

    This is the Flash partition in the linker script

    If the parition are wrong, then the image size lesser than 64kb shouldn't work. but only the images greater than 64kb are not copying from download partition to APP partition. 

    And if we want to compile in the larger memory model is there any specific changes to be done in the linker script?

    Regards

    Kokila

  • 0 in reply to Kokila K
    Guru 26335 points

    The failure for sizes greater than 64K suggests that you used a variable of size int where you should have used a long somewhere. For an index into one of those program spaces perhaps.

  • 0 in reply to David Schultz
    Prodigy 135 points

    Hi David,

    But I have used an uint32_t variable variable everywhere. Is there any other possibilities?

  • 0 in reply to Kokila K
    Guru 26335 points

    Lacking anything resembling your code to look at, all I can do is guess. Not the best method.

    You of course also have a debugger. You can set a breakpoint and examine in detail what happens when you reach that 64K boundary. What variables do, etc.

  • 0 in reply to David Schultz
    Prodigy 135 points

    I could understand since am flashing via i2c method, Unluckily the debugger is not working. since once the image is downloaded iam going for a software reset. and the mcu starts from beginning and the debugger becames unavailable.

    This is my corresponding code snippet.

  • 0 in reply to Kokila K
    Guru 26335 points

    A picture of your code is a lot harder to read than if you used the "Insert: code" feature of the editor.

    From what I can read, nothing jumps out as a problem. Even if it is written oddly. But missing are various helper functions that are called and of course there is the matter of if the parameters passed to it are correct.

    You have some debugging print statements. What differs in that output between cases where the write works and the write fails.

  • 0 in reply to David Schultz
    TI__Guru 56685 points

    Hello Kokila,

    Please double check your compiler settings and make sure the individual images are compiled in "large memory model". You can also double check the disassembly and if the instructions are using the extended instruction set. If youa re trying to address memory locations above the 64kB barrier, you need the extended instruction set in order to do so. 

    If you want an example of your application, please see MSPBOOT as it is an application side bootloader with dual image support across memory models. Youc an compare your code to this for further debug. Documentation can be found at www.ti.com/tool/mspbsl STEP 3: Custom Bootloaders. You can download the example SW here. 

  • 0 in reply to Jace H
    Guru 26335 points

    This seems unhelpful. The data is downloaded and stored in an area of flash memory. Then after verification (I assume that this is done on the image in flash and not as the data is received.), the data is copied from one region of upper flash memory to another. It is that last step that is causing the trouble.

    Since, I assume, the initial write to flash memory works, the problem occurs somewhere before/during the copy. It seems unlikely to be memory model trouble since the first write to upper flash works.

    Instead of copying the data after verification, I think I would have structured it to leave it in place. Switching between the two regions and saving a little wear and tear on the flash.

**Attention** This is a public forum