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.

CCS/CC3220SF-LAUNCHXL: cc3220 flash memory problem

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, UNIFLASH

Tool/software: Code Composer Studio

Hi,

I use flash.c driver in "ti\simplelink_cc32xx_sdk_1_60_00_04\source\ti\devices\cc32xx\driverlib" to write several data to flash memory. When i checked the flash memory, i can write data using flashErase and FlashProgram functions and can get return 0, it's ok. But after that, i have to call i2cClose function (or interrupted functions such as this) and module gets fault_isr issue. 

I have tried FlashIntUnregister, flashDisable functions to close flash memory interrupt but i cannot solved the issue, and could not find any code examples about using functions inside flash.c. Is there any example about this or can i get help about using this driver?

Thanks!

  • Hi,

    In CC3220SF is used internal flash for code execution. In case that you rewrite part of flash where is code located, you code need to stuck. For saving user data is recommended to use external flash by sl_ filesystem API.

    More information about internal flash you find at TRM - www.ti.com/lit/ug/swru465/swru465.pdf

    Jan
  • Hi Jan,
    Thank you for your reply. I use 32 blocks after 0x1000000 (and in trm i can see that these registers for not executable application) so i think this is not the problem.
    I have tried restarting the mcu after writing, module works this way (and that means there is no problem about code execution) but i think there should be a better way to do.
  • Hi,

    According TRM this part of flash is reserved. I think that is not good idea write into this reserved area. Also in TRM is this important statement: "When a flash memory operation (write, page erase, or mass erase) is executed in a flash bank, access to that particular bank is inhibited. As a result, instruction and literal fetches to the bank are held off until the flash memory operation is complete. If an instruction execution is required during a flash memory operation, the executing code must be placed in SRAM or another bank, and executed from there while the flash operation is in progress."
    Just imagine.... when you starts write procedure into first flash bank, where is also code located, this bank is locked. And during this time is ISR called but memory with interrupt code is still locked. This cause hard fault.

    If you really need to write into internal flash, you should select second bank (somewhere at end).

    Jan

  • Hi,
    For example i have tried for 0x10ffe00 address but the result is the same, for the addresses somewhere at end.
  • Hi,

    How big is your code? Do you have uploaded image with your code inside external flash (by Uniflash) or you have upload code using JTAG inside development mode only?

    Please share your flash write code. I can look on it.

    Jan
  • Hi,
    I am trying for both jtag or uniflash uart. You can see the code path below, as i wrote before i dont have any example so tried something like that.


    uint8_t flashWrite(uint8_t* data, uint8_t type) {


    len = strlen((char*)data);
    size = len; //needed global
    long address = 0;

    ret = FlashErase(0x10ffe00);
    if (type == 1) {
    address = 0x10ffe00;
    ret = FlashProgram(&size,0x10ffe00,4); //size
    }
    else if (type == 2) {
    address = 0x10ffe30;
    ret = FlashProgram(&size,0x10ffe08,4);
    }

    memcpy(&Reg,(unsigned long*) data, 32);


    ret = FlashProgram(&Reg,address,32); //data


    return ret;
    }
  • I think i should close the operation with something but can not find the function.
  • Hi,

    Later I will look on it, because this is a interesting topic for me. As first please check this thread e2e.ti.com/.../2308003 which can give you some additional information though not solve your issue.

    Jan
  • Hi,
    I have seen this before but couldn't solve my problem exactly. Waiting for your reply, thank you.
    Taylan.
  • Hi Taylan,

    I tested this simple code with my very complex application and it worked well.

    #define FLASH_ADDR      0x10ffe00
    
    void flashWrite(void) {
    
      long ret;
      unsigned long addr = FLASH_ADDR;
      unsigned long len;
      char data[] = "The quick brown fox jumps over the lazy dog";
    
      // erase 2kB block
      ret = FlashErase(addr);
      UART_PRINT("FlashErase: %d", ret);
      if (ret != 0) return;
    
      // len must be a multiple of four
      len = strlen(data);
      len = len + (4 - (len % 4));
    
      // write data into flash
      ret = FlashProgram((unsigned long*)data, addr, len);
      UART_PRINT("FlashProgram: %d", ret);
    }
    
    
    void flashRead(void) {
    
       // check if flash is erased
       if (*(char*)FLASH_ADDR == 0xFF) {
         UART_PRINT("NoData");
         return;
       }
       UART_PRINT("ReadFromFlash: %s", (char*)FLASH_ADDR);
    }

    But be aware that your content inside internal flash will be erased by ROM bootloader in case of change bin ary image. I did not check this but at TRM is written this:

    The CC3220SF bootloader, on every exit from power-on or hibernate, checks the integrity of the exiting (and marked-valid) user application image binary on on-chip flash against the auto-generated SHA-1 ofthe image on serial flash, saved during the program and update phase of the on-chip flash. In case of a mismatch, the on-chip flash is mass erased to protect the user application binary.

    The CC3220SF bootloader, on every exit from power-on or hibernate, checks the integrity of the exiting (and marked-valid) user application image binary on on-chip flash against the auto-generated SHA-1 of
    the image on serial flash, saved during the program and update phase of the on-chip flash. In case of a mismatch, the on-chip flash is mass erased to protect the user application binary.

    Jan

  • Hi,
    Thank you for your reply, i think it was a problem about data sizes, now it works ok. And also it doesn't need to call flashErase function for life of the flash memory.

    Taylan.