Libopencm3 interrupt table on STM32F4 - arm

I'm using libopenCM3 for my project on STM32F4. I've used previously Standard Peripheral Library and newer Hardware Abstraction Layer developed by ST.
In these libraries you have assembly file (startup file) with the definition of vector table.
This is what I'm missing for libopenCM3. Can you please show me where to find this table? Or is it done some another way?
I really need to use interrupts in my project.
Thanks.

Can you please show me where to find this table?
Interrupt vector table is located in lib/cm3/vector.c:
__attribute__ ((section(".vectors")))
vector_table_t vector_table = {
...
.irq = {
IRQ_HANDLERS
}
};
And IRQ_HANDLERS for STM32F4 are defined in lib/stm32/f4/vector_nvic.c file. This file will be available after building the library (it's generated with irq2nvic_h script). In this file you can see something like this:
#define IRQ_HANDLERS \
[NVIC_DMA1_STREAM0_IRQ] = dma1_stream0_isr, \
[NVIC_ADC_IRQ] = adc_isr, \
...
Functions like dma1_stream0_isr() and adc_isr() are defined like this:
#pragma weak adc_isr = blocking_handler
So these functions are just blocking handlers by default. But they are defined as weak, so you can easily redefine them in your code.
Or is it done some another way?
As discussed above, it boils down to next: you just need to define interrupt handler function (ISR) with correct name in your code, and your function will be placed to interrupt vector table automatically.
For instance, if you want to handle UART2 interrupt, just implement usart2_isr() function somewhere in your code. For the whole list of ISR function names refer to include/libopencm3/stm32/f4/nvic.h. But those names are usually pretty straight-forward.
Also, check out the libopencm3-examples project. The chances are you will find just what you need there.

Related

Where is the ISR macro's definition located for AVR microcontrollers?

I've looked through both <avr/io.h>, and <avr/iom328p.h> for a macro which defines the ISR macro, as well as the datasheet for the ATmega328P and I have yet to find anything. All I can find is external sources saying that you make an interrupt service routine by writing
ISR (/*<ISR-vector>*/)
{
/* ISR code here */
}
but I haven't found its source/definition anywhere.
The macro is defined in avr/interrupt.h, which you can view for example here (github mirror, not an official source). In case you were looking for it to understand how it works i also recommend you read about interrupt and signal function attributes here, because all that the ISR macro does is define a function with a specific attribute and name.

GCC 8 for ARM in LTO mode is removing interrupt handlers and weak functions - how to prevent it?

My target device is an EFM32 Cortex-M3 based device. My toolchain is the official ARM GNU toolchain gcc-arm-none-eabi-8-2018-q4-major.
Everything works fine without LTO, but to make LTO work I have to mark all interrupt handler code with -fno-lto. I would like to get rid of this workaround.
The problem is, every interrupt handler is getting removed from the final binary. (I am checking with arm-none-eabi-nm --print-size --size-sort --radix=d -C -n file.out) This makes the resulting binary crash.
Digging deeper and after googling for similar problems:
I tried marking such functions as __attribute__((used)), __attribute((interrupt)) to no avail - the interrupt handlers are getting removed in spite of these attributes. (related Prevent GCC LTO from deleting function)
Found possibly related discussion https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966 - no solutions posted
Sample code from startup_efm32gg.c defines default interrupt handlers as such:
void DMA_IRQHandler(void) __attribute__ ((weak, alias("Default_Handler")));
/* many other interrupts */
void Default_Handler(void) { while (1); }
The same problem happens for regular interrupt handler definitions as well (as in, no aliases and not weak)
It might be related but it seems that weak symbols are misbehaving in LTO mode in the same way.
Thank you in advance for any ideas!
Edit: See my reply to the marked answer for a full solution!
Where are your interrupt handlers referenced from? Just like unreferenced static functions and objects will be removed from a single translation unit, external ones that are unused will be removed during LTO. In order to prevent this (and in order for your program to be valid anyway in the abstract model) there needs to be some chain of references, starting from the entry point, leading to the functions and objects; if none exists, then you're not actually using them in your program.
If the reference is from a linker script or asm source file, it's possible that this is a bug in LTO, and it's not seeing the references like it should. In this case you might be able to apply a hack like __attribute__((__used__)) to the affected function definitions. Alternatively you could make fake references to them, e.g. by storing their addresses to dummy volatile objects or using their addresses in input constraints to empty inline asm blocks. As yet another alternative, there may be a way to redo whatever you're doing with asm source files or linked scripts to make your interrupt table at the C level, with appropriate structs/arrays in special sections, so that the compiler can actually see the references without you having to fake them.

tiva c implicit function

I am trying to build a simple logic analyzer with TM4c123 but anytime when I use the function ROM_.... it appears to be an error( implicit of function ROM_..) Anyone knows why?
for example:
ROM_FPUEnable();
ROM_FPULazyStackingEnable();
// run from crystal, 80 MHz
ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
// enable peripherals
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
// set UART pins
GPIOPinConfigure(0x00000001);
GPIOPinConfigure(0x00000401);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
// init PORTB
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
GPIO_PORTB_DIR_R = 0x00;
GPIO_PORTB_DEN_R = 0xff;
// configure uart
ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 115200,
(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
All of the function ROM are errors, why? I already include rom.h and rom_map.h
You probably didn't defined your target device.
Try to add something like -DTARGET_IS_TM4C123_RB1 to your Makefile.
This define is necessary in order for the ROM_* symbols be defined.
You are using a combination of driverlib (tivaware) and direct register modification (DRM). Use one or the other, preferably driverlib.
You should actually be using the MAP_ calls instead of ROM_. ROM_ is deprecated but still usable for testing. Don't put ROM_ in production code. I know the examples still use ROM_.
You are missing the header file for ROM anyways. If you want to use ROM_, you need to include driverlib/rom.h. That's why it's complaining about the implicit function call. Any call to a ROM_somethingsomethingdarkside() is not defined. You will also need to include stdint and stdbool, as driverlib uses those c99 types. To use the map calls, you'll need to include driverlib/rom_map.h
You may also need to include driverlib/gpio.h, driverlib/sysctrl.h. Not sure on that. I've never mixed things like you have done, and I always debug using the compiled in driverlib first, then prefixed the driverlib calls with MAP_ after I know things are working. I haven't ever gone back to remove my includes for the compiled in driverlib libraries. The toolchain seems to be smart enough to not compile them in after I stop calling them anyways. Now I kinda want to try that though.
To be clear, ROM_ or MAP_ is calling driverlib calls out of the on chip ROM.
I suspect that you are not sure what the code you are using really is and what it does by the way you're mixing DRM and driverlib libraries. I HIGHLY suggest you take the time to go through the online workshop for the Tiva C. It's a series of short videos and labs that will clear up all of this. I went intentionally neurotically slow and it took me a weekend. You can do it in a day, and it'll be a day well spent. It'll save you that many times over. It's out of date slightly as far as code composer goes, but it's still useable. I have all my students go through it before they start work on this platform.
http://processors.wiki.ti.com/index.php/Getting_Started_with_the_TIVA™_C_Series_TM4C123G_LaunchPad
Edit: yes, and as vitor points out, you also need that define as well.
I would reccommend using "driverlib/gpio.h" and "driverlib/sysctl.h"
for the Pin configuration with TM4C devices

Automatic compile-time mechanism for calling initialization code of modules in C

We are in the process of modularizing our code for an embedded device, trying to get from $%#!$ spaghetti code to something we can actually maintain. There are several versions of this device, which mostly differ in the amount of peripherals they have, some have an sd card, some have ethernet and so and on. Those peripherals need intialization code.
What I'm looking for is a way to execute the specific initialization code of each component just by putting the .h/.c files into the project (or not). In C++ right now I would be tempted to put a global object into each component that registers the neccessary functions/methods during its initialization. Is there something similiar for plain C code, preferably some pre-processor/compile-time magic?
It should look something like this
main.c
int main(void) {
initAllComponents();
}
sdio.c
MAGIC_REGISTER_COMPONENT(sdio_init)
STATUS_T sdio_init() {
...
}
ethernet.c
MAGIC_REGISTER_COMPONENT(ethernet_init)
STATUS_T ethernet_init() {
...
}
and just by putting the sdio.c/ethernet.c (and/or .h) into the project initAllComponents() would call the respective *_init() functions.
TIA
There is nothing in plain C that does this. There are however compiler extensions and linker magic that you can do.
GCC (and some others that try to be compatible) has __attribute__((constructor)) that you can use on functions. This requires support from the runtime (libc or ld.so or equivalent).
For the linker magic (that I personally prefer since it gives you more control on when things actually happen) look at this question and my answer. I have a functional implementation of it on github. This also requires gcc and a linker that creates the right symbols for us, but doesn't require any support from the runtime.

GCC alias to function outside of translation unit -AKA- is this even the right tool for the job?

I'm working with FreeRTOS on an STM32 (Cortex-M3), and using the CMSIS library from ST to bootstrap everything.
The CMSIS library defines the weak symbol SVC_Handler in the startup ".s" file. It must be overridden somewhere in order to get your ISR in the interrupt vector table. FreeRTOS defines vPortSVCHandler, which is the ISR I want to have handle the SVC interrupt.
I would like to "glue" the two together using my application code (i.e. w/o modifyng FreeRTOS or the CMSIS source code). I thought an alias would be the right tool for the job, so I tried this (in a separate source file, main.c):
void SVC_Handler(void) __attribute__ ((alias ("vPortSVCHandler")));
That results in: error: 'SVC_Handler' aliased to undefined symbol 'vPortSVCHandler'
Turns out, according to GCC documentation here http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html, in order to use the alias attribute, you cannot alias a symbol outside of the translation unit. So I thought I'd try to extern the symbol into main.c like so:
extern void vPortSVCHandler( void ) __attribute__ (( naked ));
void SVC_Handler(void) __attribute__ ((alias ("vPortSVCHandler")));
This generates the same error. Any suggestions???
I would really like to avoid modifying either of the libraries. I know I could write a function SVC_Handler that simply calls vPortSVCHandler, but that could add unnecessary overhead to the ISR (possibly depending on optimization settings). Note: The FreeRTOS examples accomplish this via a custom startup file. I'm looking for a way to do this from C or my linker script.
Compiler Version: gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42)
Target: arm-none-eabi
You should be able to do this either with a linker script, or by passing the appropriate option to the linker, eg. for ld, --defsym=SVC_Handler=vPortSVCHandler
See the binutils documentation for more information on the ld --defsym option, and assignments in linker scripts
I think the problem with alias is, that it expects a declared and defined function, since it is just an alias. You want to use it as a forward-declaration of another function. I got a similar thing to work like that:
void SVC_Handler(void) asm("vPortSVCHandler");
This renames the entry point of the SVC_Handler, and if you then do not define it, it should find vPortSVCHandler.
See: https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
Another solution that I gleaned from one of the FreeRTOS examples is to add the following to your FreeRTOSConfig.h ...
/* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS
standard names - or at least those used in the unmodified vector table. */
#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
The original file is from FreeRTOS/Demo/CORTEX_M0_LPC1114_LPCXpresso/RTOSDemo/Source/FreeRTOSConfig.h which also integrates the CMSIS system clock into the config. A very nice starting point for a CMSIS/FreeRTOS project.
I'm pretty sure SVC handler is only used by FreeRTOS
at initial startup, so adding an indirection exception
handler isn't going to hurt performance (but its
ugly). Best ask this on the FreeRTOS forum, response
there is usually great.
Hope this helps, Best Regards, Dave

Resources