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

[TKB]

I am using CodeWarrior and an example program from your website to understand the functioning of the FXTH870911 chip. The program I am using is called FXTH_FW_BLE_Beacon_by_GenFSK. 

One of the factory loaded functions present in the code is TPMS_LF_ENABLE(). Since we can't view the source code of this function, I try to step over it, but strangely enough it still steps into the function and then gets stuck there. I see the "no source available" message and the disassembly as shown in the screenshots below.

How do I exit out of this function or rather not enter it in the first place?

Thanks

Tushar

[TKB]

Hi Tomas

In the window below, do I just click "Reset"?

I did try everything like you suggested but it is still entering Disassembly. 

Are you not able to recreate this problem at your end?

Thanks

Tushar

[TomasVaverka]

Hi Tushar,

Yes, it is necessary to click “Reset” for the debugger to actually perform the software reset.

I hope it will work this time.

Best regards,

Tomas

PS: Please use the “Reply” button at the bottom of the latest post to keep the right order.

[TKB]

Hi Tomas

Actually it didn’t work

I wonder if you’re able to recreate this problem at your side?

Tushar

[TKB]

Hi Tomas

I was wondering if I am seeing this problem because I accidentally deleted the factory loaded firmware functions? I am not sure if I did but that's what my suspicion is.

Anyway, I did a disassembly of the main.c code before debugging and saw that there is actually something happening in the firmware/ library functions and it's not just some random FFFF code. 

112: TPMS_LF_ENABLE(CLEAR);
0000001A 4F CLRA
0000001B CDE072 JSR 0xE072
115: TPMS_READ_ID (TPMS_ID);
0000001E AE00 LDX #TPMS_ID
00000020 8C CLRH
00000021 CDE06F JSR 0xE06F
00000024 2022 BRA *+36 ;abs = 0x0048 

So I am not sure yet what to make of it. Any suggestions will be really appreciated.

Thanks

Tushar

[TomasVaverka]

Hi Tushar,

Via the debugger, you can check if the firmware is still present or not: in the “Memory” panel, click on the green plus and enter the address “0xE000”. If the content is the same as my screenshot then the firmware is still there. If the memory is filled with FF then it is empty.

In any case, you can use what we call the “library model” instead of the “firmware model”. In the library model, the embedded firmware is erased (but the trim is not) and the application has access to the entire flash memory (except the trim). In CW, there is no problem of “No source found” anymore because the flash is not separated between firmware and user flash. Detailed information can be found in AN12523. Demo projects using the library model can be found in the Starter Package for FXTH87/E to be downloaded from here.

Best regards,

Tomas

[TKB]

Hi Tomas

The firmware is definitely erased as you can see below.

I wanted your confirmation one another thing -

After compilation and linking, I looked at the linker generated map file and I couldn't find the TPMS_LF_ENABLE function in it. Could this be related to the firmware getting erased?

Also, I thought I was using the Library model since I had installed the FXTH870000_LIB_CW_patch and also this is how my project structure looks:

It has the FXTH870000.c and .h files which I think is required for the LIB functionality. Am I right?

Thanks a lot!
Tushar

[TomasVaverka]

Hi Tushar,

Yes, the firmware has been erased, which could have been done by programming a library-model project into the chip. Programming a library-model project into a chip erases the embedded firmware, so the chip does not support firmware model anymore after that.

In firmware-model projects, the flash is separated between user flash and firmware flash. The firmware functions are programmed by NXP in the firmware flash, and the user's developed application code to be programmed in the user flash. The user flash does not contain the firmware functions, so it is normal that they do not appear in the map file. Taking a look at the declaration of TPMS_LF_ENABLE, you can see that there is actually just an instruction to jump into the firmware flash, where the function had been programmed by NXP.

To use the library model, the project must use the FXTH870000_LIB target. Projects using the FXTH870000 target are firmware-model projects. In the starter package, four projects are provided: two firmware-model projects and two library-model projects, highlighted in yellow:

Best regards,

Tomas

[TKB]

Hi Tomas

I went through the Firmware vs Library model app note. Since these are the relevant memory sections, so I looked at them:

E0A0 to FBFF:

FC00 to FD3F:

FD40 to FDFF:

FFB0 to FFBF and FFE0 to FFFF:

Looks like everything is as expected. 

Do you see anything concerning or can give some suggestions?

Thanks a lot,

Tushar

[TomasVaverka]

Hi Tushar,

The screenshots show that the embedded functions have been erased, but not the trim page. So the chip is still functional, but can only use library-model projects.

Best regards,

Tomas

[TKB]

Hey Tomas

Even though I am using Library Mode, why does the disassembly still contains JSR (jump to subroutine) to a memory location where nothing is stored?

e.g. the below snapshot.

This is the whole problem. Shouldn't it instead be jumping to a memory location within the trim section like you mentioned?

Thanks

Tushar

[TomasVaverka · Accepted solution]

Hi Tushar,

The assembly code in the screenshot is extracted from the project FXTH87_E_FW_LF_Rx_RF_Tx, which is a firmware-based project. The body of the functions are not present in the projects. Instead, the program jumps to the firmware section as described in the file Firmware_lnk.h of the project:

To work with the library model, please use the FXTH87_E_LIB_LF_Rx_RF_Tx project. In this project, the functions are added from a library:

In the assembly code, we can see the program jumping at the address where the function is actually stored. For example, to execute TPMS_RF_ENABLE the program jumps at 0xC68B:

And we see in the map file that the function is stored at this address:

As explained in AN12523, in library-model applications the user code and firmware library functions can be stored anywhere in the FLASH except the trim zone. The trim zone from 0xFC00 to 0xFDFF is reserved to trim coefficients, which are coefficients used to operate the sensors. These coefficients are not functions.

Best regards,

Tomas

[TKB]

Hi Tomas

Thanks so much for your patience and continued support! I finally have this figured out. Just so that anyone reading this in the future understands clearly the steps that I followed, here they are:

The right place to start is the FXTH-STARTER-PACKAGE. Within it, you will find a PDF titled "Including a library in a CodeWarrior project". This is what I was missing all along! As it turns out, you have to include a .h and a .lib file in your project (these are reference to the firmware functions/ macros that your user code calls) and these two files are found in the FXTH_LIB_Firmware_Libraries folder within the same package. You also have to go to your project properties to include this newly added lib file in the linker search path. Then include the .h file in your main source code.

The example project FXTH87_E_LIB_LF_Rx_RF_Tx comes preloaded with these settings, so you can debug and step over functions and macros without seeing any of the issues I had listed earlier. There is one thing though - when you step over _asm STOP, you will be left hanging (that is because the controller goes into STOP4 mode). However, here if you follow the steps mentioned by Tomas in one of the earlier comments (click reset, place a breakpoint and hit resume), the program will be active once again. 

So, I tried these settings with the project I was having problems with earlier (Since I am using FXTH870911 which has a 2-axis accelerometer, I used FXTH87xx_2_Axis_v32.lib and FXTH87xx_2_Axis_v32.h. Remember to comment out the default #include "Firmware_lnk.h" in the main.c file or you will get redefinition errors. This file is not needed because it is to be used only if you are using your hardware in firmware mode, not in library mode) and everything now works fine! 

Hope this helps others who might face similar problems.

Thanks a lot!

[TomasVaverka]

Hi Tushar,

In the CodeWarrior IDE, the “Step Over” command only works when there is no user breakpoint. If there is a breakpoint, then the “Step Over” behaves like a “Step Into”. I see in your screenshot that one breakpoint is present, so I suppose this is the reason why the program does a “Step Into” instead of “Step Over”.

Could you try to remove this breakpoint, and all others if any, and then retry?

Best regards,

Tomas

[TKB]

Hi Tomas

I removed all user breakpoints

But the problem persists!

Regards,

Tushar

[TomasVaverka]

Hi Tushar,

I would recommend to follow this exact procedure:

1. Start the debug session without any breakpoint.

2. When the debug session is active the program is automatically stopped at the beginning of the main. At this moment, place one desired breakpoint. Do not run the program.

3. Click on the button to do a software reset.

4. Run the program, it will stop at the breakpoint.

5. Remove the breakpoint.

6. Click on “step over”.

If this does not work, I do not have any other idea unfortunately.

Best regards,

Tomas