SparkFun Forums

[Reiik]

I'm attempting to test out some basic programs on an STM32L151RD (Cortex-M3) using IAR's Embedded Workbench. I'm using an ST-LINK/V2 programmer. I've downloaded the Standard Peripherals Library and generally have been able to get it working, with one exception. For some reason, if I use the provided startup file "startup_stm32l1xx_hd.s" the MCU just hangs when I load the program, and I end up having to use the ST-LINK Utility software to reset the MCU.

At first I thought the solution was to just not use the startup file, figuring that IAR must've included it (or something equivalent) automatically elsewhere since it compiles, loads, and runs just fine without it. That was fine until I needed to use an interrupt handler for a simple SysTick program, and of course since all of the interrupt handlers are supposed to be defined in the startup file (as I understand it), SysTick doesn't work.

Just to clarify, by "include" the startup file, I just added it to the project source like I would a .c file. If there's some other project setting I need to point to the startup file, I haven't found it.

I've looked over the list of all the files I need to include and compared against the template project, so far as I can tell I'm doing everything right. I'm new to both ARM and IAR, if anyone has any simple things I should check or any feedback on what might be wrong I'd greatly appreciate it.

[mlu]

I dont have the IAR workbench but this usually works as follows

All interrupt handler addresses must be in the vector table, thats what startup_stm32f1xx_hd.s
files contain plus 'weak' default implementations, they will be overridden if you write your own interrupt handler
with the same name. There is no need to put the interrupt handler code in this file.

The IAR libraries probably contain a similar file, but the names in the vector table might or might not be the same.
The workings is probably similar though.

The only hard restriction is that the vector table must be loaded into flash/ram where the mcu can find it at reset and
point to valid interrupt handlers, the rest, how this is coded in different libraries and toolboxed can vary.

[stevech]

I'm attempting to test out some basic programs on an STM32L151RD (Cortex-M3) using IAR's Embedded Workbench. I'm using an ST-LINK/V2 programmer. I've downloaded the Standard Peripherals Library and generally have been able to get it working, with one exception. For some reason, if I use the provided startup file "startup_stm32l1xx_hd.s" the MCU just hangs when I load the program, and I end up having to use the ST-LINK Utility software to reset the MCU.

At first I thought the solution was to just not use the startup file, figuring that IAR must've included it (or something equivalent) automatically elsewhere since it compiles, loads, and runs just fine without it. That was fine until I needed to use an interrupt handler for a simple SysTick program, and of course since all of the interrupt handlers are supposed to be defined in the startup file (as I understand it), SysTick doesn't work.

Just to clarify, by "include" the startup file, I just added it to the project source like I would a .c file. If there's some other project setting I need to point to the startup file, I haven't found it.

I've looked over the list of all the files I need to include and compared against the template project, so far as I can tell I'm doing everything right. I'm new to both ARM and IAR, if anyone has any simple things I should check or any feedback on what might be wrong I'd greatly appreciate it.

see if this function is called: iar_data_init3 or something similar. I just had a problem where the linker file (.icf) and that function are incompatible. That function initializes static variables' values, such as "int xyz = 123". It is in a .a library and no source is available.

In my case, the function just looped or hung the CPU (a cortex m4).
I called IAR and didn't get to someone who knew. I recall that I just used a different linker file that used C code instead of that function.

But this may not be your problem.