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.

Flash2803x_API function Flash_Erase() cause reboot of application

Other Parts Discussed in Thread: CONTROLSUITE

Hello, 

I am working on a TM320F28035 doing a Bootloader and I have encountered some problem with the Flash_API. I've integrated the Flas2803x_API from ControlSuite with no problem.

It is functionning correctly by itself, but can't seem to work when there is CAN interruptions working at the same time. When I disable the interruptions the Flash_Erase() function is working fine, but the rest of the time callin Flash_Erase() cause a reboot of my application.

Currently, I am disabling the interruptions during the Erase (and the Program) but the final application will need to have the CAN interrupts working even during that time. I would like to know if it was even possible to have CAN interrupts working alongside the Flash API and, if yes, how I could do it.

I welcome all the help you can give and thank you in advance.

Regards, 

Simon Brethous

  • Hi Simon,

    In theoretical scenario this shouldn't happen, what you're facing is some kind of memory conflict (for both Flash_Erase & CAN interrupt). Can you share the implementation with the flash cmd file?

    Regards,

    Gautam

  • Hi Simon,

    Is your CAN Interrupt code running in RAM or in FLASH. If the latter is the case, this will most likely be the reason of the reboot as you are not allowed to run code from flash and erase it at the same time!

    BR Andreas

  • Hi, 

    Well my guess was the same, I think that the CAN interruption are in Flash and that this is causing problem, but I tried several ways to move the interrupts functions to RAM with no success.

    I will show you one of .cmd files (I have 2 of them, a Peripherals.cmd and a MemoryWithCLA.cmd). This is MemoryWithCLA.cmd

    PAGE 0: //Data and program USER SPACE

    //RAM Space
    LoRAM : origin = 0x000050, length = 0x0007B0 /* on-chip RAM block M0 and M1 for Stack 4KbB*/
    HiRAM : origin = 0x008000, length = 0x001000 /* data RAM (L0-L3) for all other 16KbB*/
    ClaRAM : origin = 0x009000, length = 0x001000 /* data RAM (L0-L3) for all other 16KbB*/
    //Flash space
    //FIXEDFLASH : origin = 0x3E8000, length = 0x000010 /*fixed FLASH*/
    FLASH : origin = 0x3F0000, length = 0x008000 - 80 /* on-chip FLASH for program*/
    FLASH_VAR : origin = 0x3F7FF0, length = 0x000005

    FLASH_BIN (RWX): origin = 0x3E8000, length = 0x008000

    PAGE 1: //RESERVED SPACE
    CSM_RSVD : origin = 0x3F7F80, length = 0x000076 /* Part of FLASH. Program with all 0x0000 when CSM is in use. */
    CSM_PWL : origin = 0x3F7FF8, length = 0x000008 /* Part of FLASH. CSM password locations in FLASHA */
    BEGIN : origin = 0x3F7FF6, length = 0x000002 /* Part of FLASH. Used for "boot to Flash" bootloader mode. */
    OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP */


    IQTABLES : origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */
    IQTABLES2 : origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */
    IQTABLES3 : origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */

    BOOTROM : origin = 0x3FF27C, length = 0x000D44 /* Boot ROM */
    RESET : origin = 0x3FFFC0, length = 0x000002 /* part of boot ROM */
    VECTORS : origin = 0x3FFFC2, length = 0x00003E /* part of boot ROM */

    BOOT_RSVD : origin = 0x000000, length = 0x000050 /* Part of M0, BOOT rom will use this for stack */
    CLA_CPU_MSGRAM : origin = 0x001480, length = 0x000080 /* CLA-R/W, CPU-R message RAM */
    CPU_CLA_MSGRAM : origin = 0x001500, length = 0x000080 /* CPU-R/W, CLA-R message RAM */
    }


    SECTIONS
    {
    /* Allocate program areas: */
    // fixedflash : > FIXEDFLASH PAGE = 0
    .cinit : > FLASH, PAGE = 0
    .pinit : > FLASH, PAGE = 0
    .text : > FLASH, PAGE = 0
    //flashbin : > FLASH_BIN, PAGE = 0
    FlasTest : load = 0x3F0000

    Cla1Prog : LOAD = FLASH,
    RUN = ClaRAM,
    LOAD_START(_Cla1funcsLoadStart),
    LOAD_END(_Cla1funcsLoadEnd),
    RUN_START(_Cla1funcsRunStart),
    PAGE = 0

    Cla1ToCpuMsgRAM : > CLA_CPU_MSGRAM PAGE = 1
    CpuToCla1MsgRAM : > CPU_CLA_MSGRAM PAGE = 1

    ramfuncs : LOAD = FLASH,
    RUN = HiRAM,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    PAGE = 0

    /* Allocate uninitalized data sections: */
    .stack : > LoRAM, PAGE = 0
    .ebss : > HiRAM, PAGE = 0
    // .econst : > FLASH_VAR PAGE = 0
    .esysmem : > HiRAM, PAGE = 0
    .sysmem : > HiRAM, PAGE = 0
    .cio : > HiRAM, PAGE = 0


    /* Initalized sections go in Flash */
    /* For SDFlash to program these, they must be allocated to page 0 */
    .econst : > FLASH PAGE = 0
    .switch : > FLASH PAGE = 0

    /*Reserved space*/
    /* Allocate IQ math areas: */
    IQmath : > FLASH PAGE = 0 /* Math Code */
    IQmathTables : > IQTABLES PAGE = 1, TYPE = NOLOAD /* Math Tables In ROM */


    codestart : > BEGIN PAGE = 1
    csmpasswds : > CSM_PWL PAGE = 1
    csm_rsvd : > CSM_RSVD PAGE = 1
    /* .reset is a standard section used by the compiler. It contains the */
    /* the address of the start of _c_int00 for C Code. /*
    /* When using the boot ROM this section and the CPU vector */
    /* table is not needed. Thus the default type is set here to */
    /* DSECT */
    .reset : > RESET, PAGE = 1, TYPE = DSECT
    vectors : > VECTORS PAGE = 1, TYPE = DSECT

    If you have any idea about how to move the CAN interruption in RAM I'll be glad to hear it.

    Regards,

    Simon Brethous

  • Simon,

    in the cmd file you define a section "ramfuncs". Now you need to tell the linker to place your interrupt function into this section. This can be done by placing the following pragma right before your function definition (for C++):

    #pragma CODE_SECTION("ramfuncs")

    or (for C)

    #pragma CODE_SECTION(YourFunctionName, "ramfuncs")

    Hope this helps

    Andreas

    Edit: BTW you can check where your function lies by reading the linker map file...

  • Hi,

    Thank you for your exemple! I placed my CAN interrupt (CAN_int_ecan) in RAM with it and checked on the .map that it was really there.

    It's still not working though so I think I might be missing some interrupts. I tried to pu a lot of them in RAM but still...

    Perhaps ther is also something else.

    Regards, 

    Simon Brethous

  • Did you already track down the root cause of your reset. Is it an illegal isr?? there are a lot of threads in the forum covering this issue... A Wiki page is available too...

    Andreas

  • I already had an illegal_ISR problem in this project before, and in debug mode it was stopping the application. Here I have nothing of the sort, once I tried to erase I got no illegal interrupt message, just a restart of the application. I tried in mode step by step to see what was happening, but once I got in Flash_Erase() I can't see anymore.

    Also I have spent quite some time looking in the forum for someone with the same problem but the only ones I found chose to disable the interrupt (and I can't do that)

    Regards, 

    Simon Brethous

  • Simon,

    I developed a similar bootloader as yours, the difference was, that I used UART as (interrupt driven)  comm service. I had similar issues at the beginning. I disabled all interrupts except the UART int. I had had to made sure, that everything  that could be called from within the int was available in RAM (static variables, called methods if any). Once this was OK, my FLASHing code was running fine.

    So I still guess you have parts of your interrupt code running (or calling stuff) in flash. Debugging is difficult as the Flash methods are part of a library.

    See this post, probably you can get some info by reading the reset reason register

  • Hello, 

    I've been busy trying several ways to resolve my problem but I can't seem to find the solution...

    I put the line #pragma CODE_SECTION(CAN_int, "ramfuncs"); just before my function Can_int, but that wasn't working. I've also added most of the methods and functions called inside. Should I had all the variables also? 

    The thing is that my RAM is almost full already so I can't put a lot of things in it.

    You mentioned that I could see what was causing the reboot of my application, but as the cause was obvious (interrupt in RAM) I didn't try it but can this method tell me what function is causing the rebbot? (perhaps I'm not putting the right one in RAM).

    Anyway thanks for your help!! (And sorry for bringin it back...)

    Regards, 

    Simon Brethous

  • Simon,

    Simon Brethous1 said:
    Should I had all the variables also? 

    As I stated in my previous post - everything you are calling in your ISR during FLASH operations needs to be in RAM. If you are calling variables from Flash then you will have the problems you describe. Try to free some RAM just for test purpose, an put everything you need in our ISR into the free space.

    Simon Brethous1 said:
    You mentioned that I could see what was causing the reboot of my application, but as the cause was obvious (interrupt in RAM) I didn't try it but can this method tell me what function is causing the rebbot? (perhaps I'm not putting the right one in RAM).

    Yes if you go into debug mode and place a breakpoint into your illegal ISR method you should be able to read the stack and see where you come from. If debugging is not possible, you may read out the stack register and send the adress via a debug interface.

    BR Andreas

  • Hi Andreas,

    It's finally working, thanks to you! I put every variables and methods of my interrupt in Flash and now it's not rebooting.

    I still don't have the functioning that I want but it's due to the priority of the Flash_API being higher than mine.

    I will post another thread on the forum regarding this.

    Aniway, thanks for your help!