Am 18.11.20 um 23:10 schrieb Karsten Langeloh: > Hello everyone, > > no this is not the "how do i do interrupts with sdcc" question :) > I have used sdas-stm8 in the past to convert some "old" projects from > STVD to something more usable (aka Makefiles and git) and it worked > great. > > For another project I would like to stay away from assembler coding so > I thought I could use sdcc and now have been stuck for a few days > (doing this in my free time). > Maybe someone can give me a hint what I am doing wrong or missing. > > The target mcu is a stm8s208. > I have two files: main.c and isr.c > I am using SDCC : hc08/s08/stm8 4.0.0 #11528 (Linux) on Gentoo Linux > Compiling and linking works fine BUT: > In the resulting s19 / lst / map files the vector table only has > entries up to int14 (the one I defined) and directly after that the > _GSINIT code begins - starting somewhere in the vector table ...
This is done intentionally to save Flash space. To me, it looks like the "reserved" entries are reserved use as interrupt vectors in future STM devices, not "reserved" as in "no other use allowed by the user". Compare Figure 8, where the interrupt vectors are separated from the rest of the program memory with a dashed line, just like the stack is separated from the rest of the RAM ba a dashed line (which looks to me like 1024 B is the maximum stack size¹, but if the stack is smaller, some of that can be used for other data). > I could of course define a service routine for vector 24 (the last > one) but there is still address space 0x806C to 0x807F that is marked > as 'reserved' in the datasheet [1 p.47]. > Does anyone know how I can get sdcc to put the code at address 0x8080? > > […] But to find a place in > the code where this can easily be changed would require much more time > I assume (well at least not without really ugly hacks) And I am sure > the must be a better solution […] As Basil stated -Wl-bGSINIT=0x8080, is the easiest way. Philipp ¹ If you need a bigger stack, you can use SDCC's --stack-loc to place the stack ouside that 1024 B window, and then can use up to 5 KB for the stack on this device. AFAIK you just need to avoid the locations at that 0x17ff / 0x1800 border to avoid the stack roll-over limit antifeature. The stack roll-over limit is badly documented; I do not know if STM8S208 has it. While I did run into the stack roll-over limit before, the programming manual also mentions "the most significant bits can be forced to a preset value.", which I did not yet encounter. _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
