Flash28335_API_V210.lib - Flash_Erase() Question.

H,

One thought - have you have also copied the .econst section in the API from flash to RAM?  The example that comes with the API library shows how to do this. 

Regards,
-Lori

Lori,

I have the following in my linker file. This section is copied to internal RAM at application start:

   Flash28_API:
               {
                        -lFlash28335_API_V210.lib(.econst)
                        -lFlash28335_API_V210.lib(.text)
               }
                       LOAD = ZONE6A,
                       RUN = RAML0, 
                       LOAD_START(_Flash28_API_LoadStart),
                       LOAD_END(_Flash28_API_LoadEnd),
                       RUN_START(_Flash28_API_RunStart),
                       PAGE = 0

I did notice that the global data variables are not located in internal RAM, Flash_CPUScaleFactor for example.

Any other ideas that I can pursue? I am really stuck on this one.

Is it possible that somehow the C runtime is being called within Flash_Erase() and that is  causing the problems?

Is there any possibility that Flash_Erase() is somehow re-enabling interrupts?

Thank you.

H,

Yes, global variables used by the API (i.e. the call back function pointer and the CPUScaleFactor) need to be in RAM as well.

On interrupts, the the Flash API disables interrupts around time-critical loops.  To do this it saves the state of INTM and DBGM and disables interrupts before critical time and then restores INTM and DBgm after the time critical code segment.   If you have an interrupt enabled when you call the function, then its code must be accessable in RAM.    Refer to sections 14 and 15 in the API readme.pdf file.

Cheers

Lori

Lori,

Thank you for the information. I found my problem with the Flash_Erase() function not returning. As it turns out, I was not calling it from a function that was located in internal RAM, but rather a function that existed in Flash.

This brings up another question that maybe you could help with. When I have a function that is loaded in to flash, that runs from internal RAM, the debugger is unable to properly debug the code. Therefore if I want to debug a piece of code, I must conditionally compile the code to run from Flash, then  debug it, then place it back in to internal RAM after the debugging process is complete. This leads to confusion and mistakes. It is also impossible to completely debug code that must from RAM. Am I doing something wrong? Should the debugger be able to debug code that is loaded in Flash but run from RAM? I must have missed something about debugging code that has been relocated.

As far as moving CPUScaleFactor and the callback pointer in to Ram, is it possible to just include the .ebss in the linker file along with .text and econst? Example:

   Flash28_API:
               {
                        -lFlash28335_API_V210.lib(.econst)
                        -lFlash28335_API_V210.lib(.text)
                        -lFlash28335_API_V210.lib(.ebss)
               }
                       LOAD = ZONE6A,
                       RUN = RAML0, 
                       LOAD_START(_Flash28_API_LoadStart),
                       LOAD_END(_Flash28_API_LoadEnd),
                       RUN_START(_Flash28_API_RunStart),
                       PAGE = 0

I am hoping that the above will be Ok as I am compiling for large model, and have the unified memory option checked. I know that variables are supposed to be located in Page 1, but the above does seem to work. When I use the above in my linker file, I do not receive any warnings. The .map file seems to indicate that the variables are properly placed in to RAM but I want to make sure this is valid.

Thank you !!!

H,

The best way to check, as you have already done, is the map file.  If it shows them in RAM then you are good.

On debugging the RAM functions.  I think I know what is tripping you up. 

First thing is to understand what happens when you set a software breakpoint.  When you set a software breakpoints the debugger will go and grab the opcode value in the memory location, store it away and replace it with an ESTOP0 instruction.  When you run to the breakpoint the CPU halts on the ESTOP0 instruction.  The debugger will then put the original opcode back without you ever knowing.

So in your case lets assume you have set a breakpoint in the code that runs from RAM. You reset and run the application but you never stop on the breakpoint.   At some point the application copies instructions from flash to RAM with the CPU... When it does this it overwrites ESTOP0 and so you have lost your software breakpoint!  The debugger knows nothing about this so it doesn't put the ESTOP0 instruction back. 

One way to get around this is to run just past the copy routine and then enable the software breakpoint.

Another is to use a hardware breakpoint.  This sniffs the program bus to see what instruction is being executed instead of using an ESTOP0 instruction.  The downside is there are a limited number of hardware resources to do this so you will only be able to set two of these.  Setting a breakpoint in flash uses the hardware breakpoint resources.  Also CCS will want to set a breakpoint at the end of the program - which will use up one if this is in flash.  You can disable this behavior in the load options menu to get the resource back.

Cheers

Lori

EDIT: Corrected above - I said run from Flash when I meant run from RAM.

FYI I corrected my last post to say "breakpoint in code that runs from RAM" instead of "runs from flash".