Hi Spencer,

Nice thing to have an AtomThreads port on STM8! Congrats.

There is an "undocumented feature" concerning the stack pointer on STM8. I cannot give any detail here, but you have to ensure that the SP always remains in its (datasheet-defined) authorized range. Ususally on STM8 SP starts at 0x17FF, and can go as low as 0x1400.

You can change SP to a different value as much as you want, no problem whenever it remains it the given range.

Also as a side note the documentation is sometimes wrong about SP's reset value. Just have a look at SP's value upon reset under the debugger. This IS the real value.

About your "Dwarf error": Do you *really* need to use STVD? If you use the Ride7 IDE you should not have any problem :cool:

About the CST7_START_V_Z and the like: Depending on the requirement of your project, the most optimized startup code will be automatically picked by the linker. For instance, if you do not have any global variables initialization, or if all you globals have a 0 value upon init, the the startup will be reduced appropriately (skipping unnecessary code).
The startup sources are available in Ride's installation directory, in "Lib\Sources".

Regards,

Hi Bruno,

Thanks for your quick reply. I got pulled off supporting an older project for a few days and I'm getting back into the project I'm using AtomThreads for.

BTW, I didn't do the original STM8S port, that was Kelvin Lawson, the developer of AtomThreads. I'm just trying to tweak his STM8S port to work on the STM8L, which I figured would be a quick project.

In the STM8L15x datasheet it the memory map shows RAM located from 0x0000 to 0x07FF, with the stack starting at the top (0x07FF), and I've confirmed via the debugger that the SP initializes to 0x07FF (though the datasheet indicates that the reset value is 0x03FF)

The datasheet indicates that the stack can be 513 bytes, pointing to a minimum stack value of 0x05FF. Are the 0x1400-0x17FF numbers you mentioned for a different STM8 series?

This issue with the corruption (or whatever is causing both the program not to run correctly and the debugger to choke) is happening before the stack pointer is moved, so I'm not sure if that's the problem. The error comes up consistently on the instruction in the startup ASM that jumps to the main function.

Strangely, I tried removing all the .c files from the project and stripping down the main() function to a while(true) loop and still got corruption, almost like something's going wrong with the project file that's causing the linker to go crazy. So I started a fresh new project and copied all the source files in, and it's still having the same problem.

Unfortunately I'm unable to try out Ride7 for debugging because we're using the ST-LINK programmer/debugger.

Hi Spencer,

The SP values I gave are for the STM8S20x series. Concerning STM8L15x, you should always keep SP in the [0x600-0x7FF] range.
One easy debug trick is to write a 0xCC value (or whatever you want) at the latest address available for SP:

*(volatile unsigned char*)0x600 = 0xCC;  // Last stack byte set to 0xCC

// Later in the code, perform some SP checks
if(*(volatile unsigned char*)0x600 != 0xCC)
    ERROR();  // Last stack byte corrupted: We are dead!

Concerning your "corruption" message, the problem is probably related to your option bytes: Just open the basic example given with Ride7 (in C:\Program Files\Raisonance\Ride\Examples\STM8\Discovery) and try to debug it on your Discovery. If it succeeds, you probably forgot to place the option bytes in your application.
=> If it is the case, just copy the "STM8_ob.asm" file from the working example to your application, and it should be OK.

The baseline for this problem is that on STM8L15x, the default (all zeroed) option bytes do NOT work. I cannot understand how ST Engineers did not see this flaw during design, but anyway, the good news is that all other STM8 chips (apart STM8L15x) work fine without any option bytes defined (all zeroed).

Regards,

Hi Spencer,

When initially porting Atomthreads to Raisonance I got the same error "Error: dwarf error: Cannot find referent at offset XXX" when using Raisonance-compiled code with STVD. There was an issue with the OMF2ELF tool which cropped up with particular layouts of C structure. I reported this in June (2010) and it was fixed the following day (great support from Raisonance).

I guess you are using a recent version of the tools so you already have this fix, but thought I'd mention it just in case.

Best regards,
Kelvin.

Hi Kelvin,

It appears that I'm actually not using the latest toolchain. I'll install the latest and see if that solves the problem.

I could have sworn that I updated to the latest recently! :)

Thanks,
Spencer

Upgrading my toolchain seems to have fixed the problem! Now I feel rather silly.

The general performance of the debugger seems to have improved as well, especially the Disassembly view. With the older version I would often see the instructions get mis-aligned (e.g. analyzing as if there was an instruction at 0x8001 instead of 0x8000), but that doesn't seem to be happening any more.

Spencer