# Stepping over a library (in-built) function in CodeWarrior

I am using CodeWarrior Development Studio to program and debug the NXP FXTH870911.

To understand the functionalities, I downloaded an example project from their website. It is called FXTH_FW_BLE_Beacon_by_GenFSK.

So NXP has some built in functions in a section of the flash. These functions are factory loaded and their source code cannot be viewed. One such function is TPMS_LF_ENABLE() as shown below.

Since the code of these functions are not accessible, we can't step into the function (or you will be shown a "no source available" error). However, the problem is, that even if I try to step over this function, it still steps inside and gets stuck there. I see the "no source available" message and the disassembly as shown below.

My question is - How do I exit out of this function or not enter it in the first place?

UPDATE:

Upon expansion of the line TPMS_LF_ENABLE(CLEAR); the following macro is visible:

((void(*)(UINT8))(((UINT16)0xE072)))

When I look at the disassembly during debugging, this is what is showing at the location 0xE072:

FF STX ,X

Does this new piece of information help in understanding what the problem might be?

• If the disassembly shows a sequence of 0xFF I think there is something wrong with your project. Set the warning level to the maximum. Do you have any compilation or linker warnings or errors? -- Please read your development system's documentation. Is TPMS_LF_ENABLE() a macro? If so: You can make the tools generate the output after the preprocessor (with GCC it's the option -E)? Can CodeWarrior show the expansion of the macro? Apr 13, 2021 at 6:45
• There are no warnings and errors. The warning level is set to maximum. Also, TPMS_LF_ENABLE() is a built-in function, not a macro. Apr 15, 2021 at 15:37
• Hi @thebusybee my bad earlier. There is indeed a macro expansion and it looks like this: ((void(*)(UINT8))(((UINT16)0xE072))) Since the line was TPMS_LF_ENABLE(CLEAR); I am assuming it writes a '0' to the location 0xE072. Btw, when I look at the disassembly during debugging, this is what is present at the location 0xE072: FF STX ,X Apr 26, 2021 at 6:04
• Please edit your question with this new information, don't post it here in the comments, it's too hard to find. -- Please add the disassembly of the C code you show us. Post it as text, avoid screenshots. Apr 26, 2021 at 6:31
• As already mentioned, FF means non-programmed flash. Apr 26, 2021 at 10:36

This particular Eclipse trash IDE is useless for troubleshooting - it's one of the worst IDEs ever made, all categories. In a real debugger you'd just peek at the program counter and if it says 0xFFFF then that's a problem.

As for the error, it isn't related to you not having access to the source. The program counter has likely jumped to some location 0xFFFF where it attempts to execute instruction 0xFF... - that is, you have runaway code and the ELF file contains no C source for nonsense location 0xFFFF, hence no source available.

• Without starting the debugger, disassembly the source file and verify that there's actually proper function call there.

• If so, then you maybe didn't get the part flashed correctly (0xFFFF typically means unprogrammed flash) - perhaps Codewarrior gave you a RAM build instead of a flash one, or there was some issue during flashing.

• Otherwise you could have some run-time phenomenon such as watchdog kicking in, LVD kicking in, some other reset, or stack overflow, or unhandled interrupts etc etc.

I would strongly recommend getting a better toolchain so that you can troubleshoot these kind of issues.

• Hi @Lundin Thanks for the insights! I did disassembly the source and found proper assembly language instructions there. I verified that CodeWarrior is giving a flash build. Not sure about the resets though. Unfortunately the FXTH870911 is only supported on CodeWarrior :( Apr 15, 2021 at 14:14
• @TusharKantyBhattacharyya You can open up the linker-genrated map file and see where this TPMS_ function should go in memory then compare with the debugger memory map and see what actually went there. If it looks like valid assembler, then the part likely got flashed correctly. If it's just 0xFFFF... then it didn't. Apr 15, 2021 at 14:23
• @TusharKantyBhattacharyya Once you have ruled that out, you can start investigating runaway code or MCU resets. If you have a reset cause register, which almost every MCU got nowadays, then look there. Watchdog and LVD/brown-out are the usual suspects. Also check the stack pointer at the moment before the bug strikes. If you have a trace buffer and if you had a decent debugger, you could also have checked the instruction trace. Apr 15, 2021 at 14:27
• @TusharKantyBhattacharyya "C Runtime" (CRT) written by amateurs is also a common problem with Codewarrior. Ensure that it doesn't run all memory setup on the default RC oscillator. You might have to write a new CRT yourself, I have been forced to do so for every single Codewarrior project I ever did. Here's how you do it: stackoverflow.com/questions/47933281/…. It's not all that trivial, which is why NXP/Freescale hasn't managed to write a correct CRT during the past 20 years. Apr 15, 2021 at 14:32
• Hi @Lundin, I couldn't find the TPMS function in the linker generated map file. Apr 15, 2021 at 17:27