Topic : C source level debugging for code banked applications

Forum : 8051

Original Post
Post Information Post
July 17, 2009 - 2:08pm

We are using your toolchain with Silabs C8051F120 devices for some years and began using code banking a while ago. Since then, fully supported C source level debugging is impossible.

Problem description:

Bank 0 (32kB) is the "common area" and Bank 1 (32kB) is normally paged in, so those 64kB are flashed and visible for "non-code-banking aware" tools and applications. In our case, bank 2 is configured for additional code segments and the linker automatically infers "bridges" which add the code necessary to select the correct flash bank before calling and on return. When debugging, the application ends up in nirvana as soon as a bank 2 function is called. The code of the bridge function (disassembly) is still executed correctly and PSBANK is modified. But after the jump to the bank 2 address above 0x8000, the debugger disassembly doesn't view the correct code of this bank 2 function and "conflicts during exploration" pop ups start to show up.
We concluded the reason for this is that the flashloader of the debugger doesn't support the code banking, at least not when using the OMF-51 object format files (.aof) generated by the linker. So not all banks are flashed and there is no consistent code in bank 2. This could easily be worked around if the IDE supported the start of debugging mode without erasing and flashing at the beginning. Instead we could flash the banks correctly using the .hex-files and only load the .aof in the IDE to fetch the symbolic information for source level debugging. All attempts to "cheat" the debugger by manually preselecting the PSBANK via the SFR and then flashing the corresponding .hex file for the desired bank failed.

On the other hand, the Silabs IDE's flashloader supports banking by using individual .hex files and additionally using the .aof to load symbols. But then source level debugging is only possible for bank 0 code, all other symbols are missing and only disassembly level is supported. We accounted this to a limitation of the used OMF-51 object format, which doesn't support code banking (no wonder given that version 5.0 of this specification is from 1982). So even if your IDE would support debugging without prior erasing and flashing, we expect to face the same problem with your debugger.

A newer OMF2 format exists to extend its capabilities. But the Raisonance compiler and linker don't seem to support this format (they only support "OMF Extended", which still is non-banking enabled .aof). In contrast, the "load" dialog from the "Debug" menu in your IDE supports a "OMF51 Banked" format (.lis-files), which sounds right but we couldn't find a hint on how to generate this format.
The Keil toolchain and debugger seems to support OMF2, but of course we don't want to switch the toolchain after years of investments and experience with yours.

Bottom line: Did we get something wrong here? Is there a way to fully source level debug banked applications?

Used versions:

80C51 Tool Chain 6.4.43 (BN746-51)
RC51 Compiler V3.03.42
LX51 Linker V5.01.28

RIDE 6.10.22 (BN 758-51)

Post Information Post
July 21, 2009 - 11:26am

When selecting the bank switching mode, the linker generates several files: the .AOF file contains the common area, and various files (.Xn for bankn) for the bankable areas. When using the RIDE debugger, you have to load a '.LIS' file a small script file that lists the different AOF files to be loaded, and also various optional information.
It should work with the C8051F120 and the example project for this device (see RIDE\Examples\8051\Derivatives\Silabs\C80C51F12X\C80C51F12X.PRJ contains an application in bank switching mode.