Topic : "Cannot find Referent at offset XXXXX" errors

Forum : ST7/STM8

Original Post
Post Information Post
October 5, 2010 - 3:22pm
Guest

I'm trying to port the AtomThreads RTOS (http://atomthreads.com) to the STM8L152. It is working on the ST7 that comes on the Discovery board, so it seems like it should be pretty easy, but it's giving me trouble.

I swapped out the STM8S peripheral library and replaced it with the STM8L one, and modified all the calls to work with the new library and use USART1 instead of USART2.

I'm having trouble debugging the program, though. I can step through the assembly starting in the ROM bootloader (0x6000) and it jumps to the reset vector at 0x8000, but pretty soon I start seeing "Dwarf Error: Cannot find referent at offset XXXX", where XXXX is variable. If I scroll around in the disassembly I see it pop up a lot, at different offsets. I also can't set any breakpoints in the C code.

Not sure if it's related, but in a previous project that works fine on the same platform, the rightmost column in the disassembly at the reset vector is CST7_START_V_Z, whereas in this port that's not working correctly it's CST7_START_Z. I'm not sure where the ASM startup code is defined, and where in STVD I can set that, but on both projects I have the MCU selected the same.

thanks,
Spencer

Replies
Post Information Post
+1
0
-1
October 5, 2010 - 3:49pm
Guest

Also, to give a bit more info on AtomThreads:

AtomThreads keeps a separate stack for each thread, and on a context switch (either preemptively as a result of a timer interrupt or voluntarily) the stack pointer for the old thread is stored and replaced with the stack pointer for the incoming thread.

In a recent thread Bruno said

Quote:
I recommend NOT to reset the stack pointer manually, as there is no instruction for that on STM8

So is it a problem to manually read and write from the SP register?

+1
0
-1
October 5, 2010 - 4:21pm
Raisonance Support Team

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,

+1
0
-1
October 7, 2010 - 11:52pm
Guest

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.

+1
0
-1
October 8, 2010 - 10:33am
Raisonance Support Team

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!

Note that the "volatile" qualifier is mandatory, or the compiler will just skip the code in certain situations (it tries to be smarter than you ;^)

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,

+1
0
-1
October 12, 2010 - 9:54am
Guest

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.

+1
0
-1
October 12, 2010 - 2:47pm
Guest

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

+1
0
-1
October 12, 2010 - 3:12pm
Guest

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

+1
0
-1
October 13, 2010 - 10:16am
Guest

Hi Spencer,

Glad to hear that fixed your problem. There was also another issue (with the optimiser) that was fixed in June. For those that are interested, the first release of RKit STM8 with the necessary fixes for Atomthreads was 2.30.10.0175, released on 28th June.

Best regards,
Kelvin.