stm8 | Wolk STM8 stuff

Various older versions of misc embedded compilers tended to optimize code somewhat even when optimizations were supposedly disabled. Particularly Cosmic and Codewarrior had such quirks in older versions. Since the local variable isn't used, it is optimized away.

You can see this for yourself by viewing the generated assembler - any half-decent debugger will support assembly step debugging. If there is no stack push or index register store instruction there, then it was optimized away.

You can force the variable to get used with volatile int *ptr_aLocal.

Unrelated to your question, you should use uint8_t as far as possible nad not int, when programming 8 bit microcontrollers.

The easiest thing to do was to first read the file like so:

If you look into the STM32F103 Reference Manual p. 209, you will see that there is actually a multiplexer that decides if PA0, PB0, ... or PG0 is connected to the EXTI0 signal:

STM32F103 ExtI0 schematic

That means that you cannot connect both PA0 and PB0 to EXTI0. In fact, there are four specific bits in the alternate function input/output register (AFIO) which let you choose which pin is connected to the EXTI0 signal. Here, these bits are located in the control register AFIO_EXTICR1. See the AFIO register map in the same document for further information.

Now I don't know which setup you are using, but as I recall, I had separate functions for different interrupt request routines (for EXTI0, EXTI1 and so on).

If you want to program uCs from your C application just use openOCD (free) and send commands to it. Works with almost every popular debug probe.

As suggested in the commends, there was no other way to create a file with the main loop for only the Controller and separate it from the unit tests.

My structure looks like: main.c: - contains the includes from the firmware (app.h) and the main() with the run_app() app.c: contains all the firmware and is tested with cpputest

It is an assembler directive marking the entry point, symbol name and stack usage of a function.

According to this:

[...] the first integer is the stack space used by the call instruction plus any automatic storage used by the function. The second integer is the number of bytes stacked by the caller.

I suggest that given its name and function that it causes debug information to be inserted into the object file for use by the ZAP symbolic debugger. I am not familiar with the Cosmic tool chain, but it is also possibly used to perform stack depth analysis within the call graph by the linker.

From the Cosmic compiler datasheet https://www.cosmic-software.com/pdf/cxstm8_pd.pdf

cxstm8 provides 2 different memory models depending on the size of the application.

For applications smaller that 64k, the “section 0” memory model provides the best code density by defaulting function calls and pointers to 2 bytes.

For applications bigger than 64k, the standard memory model provides the best flexibility for using easily the linear addressing space. Each model comes with its own set of libraries.

This may be the cause for your problem. If you want to access the memory location of above 16 bit address directly you need to use the correct memory model.

You mention stm32f10x.h in the question, so I'm assuming it's about the STM32F1 series of controllers. Other series have some differences, but the general procedure is the same.

GPIO pins are arranged in banks of 16 called ports, each having it's own set of control registers, named GPIOA, GPIOB, etc. They are defined as pointers to GPIO_TypeDef structures. There are 3 control registers that affect pin outputs.

Writing ODR sets all 16 pins at once, e.g. GPIOB->ODR = 0xF00F sets pins B0 through B3 and B12 through B15 to 1, and B4 through B11 to 0, regardless of their previous state. One can write GPIOD->ODR |= (1<<4) to set pin GPIOD4 to 1, or GPIOD->ODR &= ~(1<<4) to reset it.

Writing BSRR treats the value written as two bitmasks. The low halfword is the set mask, bits with value 1 set the corresponding bit in ODR to 1. The high halfword is the reset mask, bits with value 1 set the corresponding bit in ODR to 0. GPIOC->BSRR = 0x000701E0 would set pins C5 though C8 to 1, reset C0 through C2 to 0, and leave all other port bits alone. Trying to both set and reset the same bit when writing BSRR, then it will be set to 1.

Writing BRR is the same as writing the reset bitmask in BSRR, i.e. GPIOx->BRR = x is equivalent to GPIOx->BSRR = (x << 16).

Now it's possible to write some macros like

The build target never gets created, so the commands after it are executed every time you run make (or make all or make build), so the program is linked each time.

Change your build target so that it is phony: