Proteus VSM debugging support wish

[Sparky1039]

I posted this query on the main forum and received no replies so I'll ask here.

I read a forum post some time ago that indicated mikroC may eventually generate the *.COD (or COFF) simulation support files that could be used with Proteus VSM debugging. Has there been any recent consideration for this in the upcoming release of MikroC? If not, when? If never, why not? It would be a nice compliment to the mikroC compiler.

[zristic]

Can you provide us COD and COFF files specification and we will consider how complicated it is? Thanks.

[Sparky1039]

I have no idea where to find this information. An inquiry to Labcenter Electronics might be of more help then myself. I imagine they would be interested in providing support for another compiler to include within their product offering.

Contact info:
info@labcenter.co.uk
http://www.labcenter.co.uk/

This is what I found with in the help files of Labcenters' Proteus VSM.

Using Proteus VSM as an External Debugger

To Proteus as an external debugger requires that the symbolic debug format produced by your compiler is supported by one of the loaders available in Proteus. A loader extracts both the addresses of each source line in the high level language program, and - where possible - the locations of the program variables.
Common debug formats are COD (used in the PIC world), UBROF - used by all IAR's compilers, ELF/DWARF (generic), COFF (generic) and OMF (used in 8051 circles). We also provide loaders for other proprietary formats such as the list files produced Crownhills Proton Development Suite.


Supported Debug Formats

At the time of writing the following Object Module Formats are supported. As this is a rapidly evolving area of the software however, we recommend you look at the Third Party Compilers page on the website for up to date information :
ELF/DWARF
This is the recommended debug format for use with Proteus, being both rich in detail and generic. This is generally supported by most modern compilers and we anticipate it’s support extending across the compiler range in the foreseeable future. To use with Proteus simply specify the ELF file as the program property in the schematic part for the processor.

At the time of writing ELF/DWARF is supported across the AVR and ARM7 models although this will shortly be extended to the PIC and other families.
Both the ELF (the binary file) and the DWARF (the debug file) must exist in the same directory – this should happen by default when you select ELF/DWARF as the debug format from within your compiler.

COFF
This format, while supported, is not recommended where an ELF/DWARF option is available. This is because, unlike ELF/DWARF, the COF format is somewhat compiler dependant and open to interpretation. This means for example, that a PIC compiler may represent a float in COF as an IEEE float or in Microchip’s float format and provides no explicit information as to which format it has used. More information on supported compilers for the COF format can be found on the website. To use with Proteus specify COF as the debug format within the compiler and then use the .COF file in the program property of the processors Edit Component dialogue form.

UBROF
UBROF is the debug format of choice produced by the IAR compiler range. Specify UBROF8 (not a later version) as the debug format within the compiler and then use the UBROF file as the program property of the processors Edit Component dialogue form.

You can also drive Proteus directly from within IAR’s Embedded Workbench – see Using Proteus as a Virtual ICE for more information

OMF51
OMF51 is the debug format produced by Keil compilers. Specify standard OMF51 as the debug format format within the compiler and then use the UBROF file as the program property of the processors Edit Component dialogue form.

Newer versions of the Keil compilers will also produce ELF/DWARF and we recommend you use this option where available
You can also drive Proteus directly from within Keil – see Using Proteus as a Virtual ICE for more information.

COD
COD is a debug format produced by Bytecraft and widely used in PIC circles. We do not recommend using this format if an alternative is available as the information provided is incomplete. Specifically, the limitations of the COD symbolic debug data format mean that the VSM debugging support for this product is limited to stepping through the machine code and watching specific memory locations Source level stepping and variable display are not supported.

To use with Proteus specify COD as the debug format within the compiler and then use the COD file as the program property of the processors Edit Component dialogue form.
BAS
Proteus currently provides a customer solution for Crownhill’s Proton Development Suite. After compiling your program simply specify the .BAS file as the program property in the Edit Component dialogue of the PIC processor.
SDI
The SDI format is only applicable for programs written in assembler and assembled via the source code control system in ISIS. To use, configure the Code Generation Tools dialogue form such that the correct Debug Data Extraction tool is specified (this will normally be set up for you at install time) and specify the HEX file in the program property of the processors Edit Component dialogue form.

Do not enter the name of the source file as the program property for a processor - Proteus VSM does not simulate 'C' or 'ASM' files; the CPU models load and execute binary machine code from the debug formats specified above.

[dlw]

Dear Mikroelektronika team,

please let me ask if ME-team considered some adaptations in mikroC for Proteus VSM support. Please be aware that Proteus VSM is a most common tool for µC's program developments. I think to keep mikroC as usable tool for progamming µC's there is no way around supporting Proteus VSM !!

Regards
dlw

[zristic]

We would like to do support for Proteus, but it is of a low priority. Simply, it can be done by any other user, it is not strictly connected to our work.

Therefore, we need a volunteer to do this, we will support him/her at maximum.

[dreamcatcher]

I writed script for the reformat from mikroASM to MPASM. It was wery sucessfully reformating mikroC generated ASM files to MPASM file.

http://hack.sytes.net/projects/mikroASM/rep_en.zip

[zristic]

I writed script for the reformat from mikroASM to MPASM. It was wery sucessfully reformating mikroC generated ASM files to MPASM file.

http://hack.sytes.net/rep_en.zip

I get this error:

Forbidden

You don't have permission to access /rep_en.zip on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

[dreamcatcher]

I fixed it.

[dlw]

Hi,
tested with the µC example (comes with the MikroC installation) :
Examples\EasyPic3\P16F877A\LED_Blinking\

cscript rep_en.vbs LED_Blinking.PPC 12
cscript rep_en.vbs LED_Blinking2.PPC 12 (c-code was changed before from PORTB to PORTC)

- Led_Blinking.c : work fine after converting the asm file to MPLAB - asm and hex in spite of MPLAB error messages:

Message[302] C:\TEMP\1\LED_BLINKING_MOD.ASM 44 : Register in operand not in bank 0. Ensure that bank bits are correct.
Warning[202] C:\TEMP\1\LED_BLINKING_MOD.ASM 53 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING_MOD.ASM 55 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING_MOD.ASM 69 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING_MOD.ASM 77 : Argument out of range. Least significant bits used.
Loaded C:\TEMP\1\LED_Blinking_mod.cod.
BUILD SUCCEEDED: Tue May 29 16:24:00 2007


- Led_Blinking2.c : only every second (2nd) LED does blink after converting

MPLAB error messages:
Message[302] C:\TEMP\1\LED_BLINKING2_MOD.ASM 45 : Register in operand not in bank 0. Ensure that bank bits are correct.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 54 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 71 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 78 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 80 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 94 : Argument out of range. Least significant bits used.
Warning[202] C:\TEMP\1\LED_BLINKING2_MOD.ASM 102 : Argument out of range. Least significant bits used.
Loaded C:\TEMP\1\LED_Blinking2_mod.cod.
BUILD SUCCEEDED: Tue May 29 16:21:35 2007


Btw., I don't know how to handle the 'memaddr' parameter ! I used 12 but without understanding the sense.

[dreamcatcher]

mikroC doesn't put the EQU code, required from STACKS file registers into mikroASM file. General Purpose Registers block changing to PIC number.

Example:

PIC16F84A General Purpose Registers:
BANK0 - 0C~4F

PIC16F87X General Purpose Registers:
BANK0 - 20~7F

memaddr parameter for the STACKS starting address.

[dlw]

thank you very much for clarifying the function of memaddr parameter.

I tested again the 'blinking2' example by converting in the following manner:

cscript rep_en.vbs LED_Blinking2.PPC 32

But nevertheless the MPLAB hex file doesn't run properly.
The assembling error messages are the same as in my last post reported.
Only four of the eight LEDs are blinking.

There is an error by converting decimal numbers. For example :
mikroC asm 'MOVLW 255' was converted to MPLAB asm 'MOVLW 255' too. But Microchip assembler doesn't interpret the '255' as decimal number - MOVLW .255, or MOVLW D'255' would be right !

After changing all relevant code lines the hex file works fine.