Cortex M USB Fault ISR

Joshua,

We found an issue with that example recently. Please change the initialization model in the build options:

Build -> ARM Linker -> Advanced Options -> Runtime Environment -> Initialization model

Set it to use the ROM model instead of the RAM model. Hopefully that will fix your problem. If it doesn't, please let me know and I'll investigate further.

Thanks,

Is there a solution that does not use ROM?

In the long run my application needs to use source controlled software.

Joshua,

The autoinitialization model just determines how the C environment sets itself up. If you're loading your code into flash, you need to use the ROM model so the global variables get initialized correctly. If you want to load your code into RAM, make sure you use an appropriate linker command file (one with RAM in the filename).

I wrote a long explanation of the autoinitialization models elsewhere; it's pasted below if you'd like to learn more.

-----------------

You don't have to do anything different in the program source code. The linker command file must specify where to put the .cinit section (flash) and the .data section (RAM). Initialization is done as part of the C environment setup, as described in section 6.9.3 of the ARM compiler manual (spnu151). I'll try to summarize here.

From the linker's point of view, there are a few different kinds of C variables:

* Constants, which go in the .const section
* Uninitialized global and static variables, which go in the .bss section
* Initialized global and static variables, which go in the .data section
* Local variables, which go on the stack (not in any section)

To set up the C environment, the .bss section must be cleared (all zeros). This is done by the c_int00() function, which is called by the reset ISR (startup_ccs.c). When c_int00() is done, it calls main(). So all this happens before any application code runs, unless the user provides their own reset/initialization code.

When .bss is cleared, the .data section must also be filled with the initialization values. This is done differently depending on the initialization model:

* RAM model: Initialization values are loaded directly to .data, in this case by Code Composer Studio.
* ROM model: Initialization values are stored in the .cinit section, then copied to .data at run time by c_int00().

So for the ROM model, your linker command file needs a .cinit section and a .data section. They work like the load address and run address for the RAM functions, but the linker and standard library handle the data copy for you.

The .const section doesn't get copied anywhere. It can stay in flash because it's not allowed to change in the program.

Here's some example code showing what goes in the different sections using the ROM model.

------------------------------------------

//Outside of any function
int a;                        //.bss
int b = 10;               //.data (copied from .cinit)
static int c = 20;    //.data (copied from .cinit)
const int d = 30;    //.const

void myfunc()
{
       int e;                      //stack
       static int f = 30;  //.data (copied from .cinit)

       ...
}

------------------------------------------