ARM-GCC issue

This may seem off-topic, but it is a problem for me. I am new to ARM. Here is the problem.

In order to write code that is maintainable by others, I write software with each interrupt service routine and the non-interrupt code that relates to it in one file. Thus, I have a set of files, each of which that captures some major function of the project in its entirety. System-wide code goes in another file. This makes the code maintainable by major system function which I find works well. The philosophy is that all of the code that relates to a system function is found in one place.

The problem arises when I have to have dummy exception vectors, ads the ARM gcc compiler needs. In this case, I have to ensure that a given vector is defined in one and only one place. That means that I have my file containing a given system function (capturing data from an ADC, say) but I also must define the other vectors and not the ADC vector in an “unexpected exception” file. Now I have two places to edit.

To solve this, is there any way to cause the vector table to be initialized with a pointer to the “unexpected exception” interrupt handler (done in a system file) and then have specific vectors re-initialized with actual interrupt-handler pointers for the anticipated exceptions? I would also want to do this in a way that was independent of the order in which functions were compiled.

Or am I off base? Help and insight would be appreciated.

Best regards,

Peter

in a separate source file and the other code in a set of files by code function (sometimes more than one function per file). This keeps code highly modular.

The ARM version of GCC, at least as it pertains to the STM32, requires

In order to write code that is maintainable by others, I write software with each interrupt service routine and the non-interrupt code that relates to it in one file

This is what I do, but I’m a little confused by the rest of your post. I have one function in my system file, that initialises all of the interrupt handlers etc to NULL. The each functionality, SPI, I2C will place it’s interrupt handler in the vector if it’s initilisation function is called. Am I right in understanding that you are not defining the interrupt handlers to NULL in your system file, but instead initialising them to a function. Then you want to have the same function (name’d) in, say your I2C module, as the function for that interrupt number. If you can’t have the interrupt vectors be NULL, why not define say a irg_i2c_dummy function to be the interrupt handler in your system file, and have a real irq_i2c in your I2C module.

hope that made sense,

Andy

Take a look at the [“weak” and “alias” attributes.

This is a GCC extension.](Using the GNU Compiler Collection (GCC))

Andy4us

How did you initialize the vectors? I have a piece of code that initializes them by defining functions for all handlers, where the functions just call another function that handles unexpected exceptions. When I try to define the real handler, the compiler properly complains about a function with multiple definitions. I can solve this by commenting out the definition in the unexpected exceptions code but then I have to edit in two places for each function.

I could presumably use conditional compilation to do this, but then the result would be entirely dependent on the order in which the functions were compiled. If someone maintaining the code (like me, in six months to a year) had to work with it and inadvertently changed the compilation order, the code would magically change! Not good.

Can you post a code snippet with our vector initialization?

Bets regards,

Peter

gregson, denial already gave you a solution, you can create a single function that serves all the undefined interrupt sources.

__attribute__ ((interrupt ("IRQ")))
void commonfunc(void) {
  /* do something for undefined sources */
}

__attribute__ ((weak, alias ("commonfunc")))
void source1(void);

__attribute__ ((weak, alias ("commonfunc")))
void source2(void);

__attribute__ ((weak, alias ("commonfunc")))
void source3(void);

/* etc */

The weak symbols can be redefined in other modules without have the linker complain about it.

gdisirio and denial,

Thanks for the reference and code snippet. I read the reference that denial posted, but having never needed this capability before (I am an ex-AVR programmer and this was not an issue) and a new ARM programmer, the reference did not mean much to me. The snippet is most helpful and cleared up much confusion.

Gentlemen, please rest assured that I am not afraid of hard work, nor of digging through the literature. I have over 30 years experience in embedded systems and new product design, and in teaching embedded in E&CE. Seeking assistance from knowledgeable others is known to be one of the best ways to learn, and to advance all of us as fast as possible. Many of us who seek help are not being lazy, we are truly puzzled even after having tried hard, in my case, for over three days which included reading, web searches, looking for examples, etc. We appreciate the help and will pass the favour on to others.

Please recognize that everything is easy when you know how, and much of the documentation is written as if the reader is already an expert in the specifics and knows what question to ask and what words to use to find the answer. In an unrelated but similar case, it took me many days to find the pin function to pin number mapping for the STM32F103 processors. Web searches failed to find the document because I was using the wrong search words. It was not in the relevant tech reference manual, an obvious place at least to me.

I am looking for a detailed instruction set description for the Cortex-M3 that shows the invocation, timing, flags affected and arguments for each instruction. I have found the instruction set summary for the Cortex-M3 processor on the ARM website but it doesn’t give me all of the info. Does anyone know where to find it?

Thank you for your assistance.

Regards,

Peter

I recently completed the port of my project on the STM32, it is a really powerful micro controller, very very fast. It is, however, not the easiest one to work with… mainly because the very sophisticated interrupt architecture.

The documentation you need is on the ARM web site, you should download the following documents:

Cortex™-M3

Revision: r1p1

Technical Reference Manual

and

ARMv7-M Architecture Application

Level Reference Manual

If I remember well a registration on the web site is required in order to download them.

regards,

Giovanni

Thanks, gdisirio.

Regards,

Peter