Hey Guys,

I just wanted to share with you a project in order to get some constructive feedback.

MDX is an Assembly Simulator for 8-bit AVRs. It has an integrated Disassembler, which reconstructs labels and comments in order to increase readability.





What's different ?
- Backstepping is supported
- Headless Mode
- Redefine constants or even mnemonics on Source level
- Open up to 4 files and switch fast between them

Currently there are 3 different modes:

(i) Interactive Simulation
MDX accepts Hex Files as input, then decodes them into readable Assembly Source Code. Now you may step through your Code.

(ii) Headless Mode
MDX accepts a single hex file as input. This file will be silently simulated and the end state of the MCU will be printed out directly in form of a JSON File. This may be interesting for fuzzing and testing.

(iii) Disassembler
MDX will disassemble Hex Files, while reconstructing Labels, new lines and comments. The output will be printed out directly.

In the future:
- I will be working on an interactive Graph to show off relations between code segments.
- Watchpoints, Step in/out, etc.
- Adding more MCUs with different architecture
- many more...

Reason of this post:
MDX is still in development, although it is possible to simulate more complex algorithms like a recursive DFS in a Graph, some instructions are still missing (over 60 instructions are supported).

And now I am asking for some feedback. What's wrong/good, what should be added/removed, etc.

I would be happy to hear your opinion

Written in: C++
OS: Linux/Unix
Github: https://github.com/Milo-D/MDX-Assembly-Debugger/

 

Looks quite interesting. Is there any hardware requirement? Is it just firmware simulation (e.g., like MPLab SIM) or can it actually simulate with hardware attached?

Unfortunately, I do not do AVR, only PIC with MPLab 8.92. It would be nice to be able to backstep occasionally. I like that addition to your project.

As for comments, it appears they are mostly a translation of the mnemonic rather that somehow capturing the author's comment. That is still a useful addition. If it somehow captures the author's comment, how is that done starting with just hex code?

Overall, it looks like a nice project. How about doing the same for PIC?

 

Looks quite interesting. Is there any hardware requirement? Is it just firmware simulation (e.g., like MPLab SIM) or can it actually simulate with hardware attached?

The plan on this was: First you will be able to simulate incoming data on pins via a simple command like write <destination> <data>.
After finishing the core, I will be working on simulating common extern peripherals.

As for comments, it appears they are mostly a translation of the mnemonic rather that somehow capturing the author's comment. That is still a useful addition. If it somehow captures the author's comment, how is that done starting with just hex code?

Unfortunately it is not possible to recreate author's comments by decoding plain hex. That's why I am adding mnemonic related comments to every line. But you can easily redefine comments, constants, labels and even mnemonics while debugging.

Overall, it looks like a nice project. How about doing the same for PIC?

I already thought about adding different MCUs to MDX. I will work on it as soon as the core is finished. Do you have a special PIC in mind ?

Also, thank you for your feedback means a lot to me.

 

I use mostly enhanced mid-range PIC's, like the 16F1829 (aka 16F1xxx) and related. Unfortunately, MPLab 8.92 does not support the newest PIC's like the 16F1xxxx (e.g., 16F18856) or even newer 16F1xxx. The instruction sets are all the same 49 instructions.

Before you consider wasting time on doing that, consider that many users have switched to MPLab X IDE (https://www.microchip.com/mplab/mplab-x-ide), and I will probably have to do that too. Initially MPLab X seemed to be developed for users of C, and Assembly writers like me were stuck with the older platform. I have tried X twice and found it unusable; however, maybe its time to try it again as I have seen some Assembly coding done using it and reports that it is much improved compared to its early releases. I do not know whether MPLab X can backstep. That is certainly not essential, but there have been times it would have been helpful.

Another helpful addition when writing (but not necessarily debugging) would an ability to add tabs so one could jump back and forth between them. With just a few pages, that is not needed, but as the length of the code increases, it would be helpful. Now, I just print everything out and add sticky tabs to the printed version.

 

Before you consider wasting time on doing that, consider that many users have switched to MPLab X IDE (https://www.microchip.com/mplab/mplab-x-ide), and I will probably have to do that too. Initially MPLab X seemed to be developed for users of C, and Assembly writers like me were stuck with the older platform. I have tried X twice and found it unusable; however, maybe its time to try it again as I have seen some Assembly coding done using it and reports that it is much improved compared to its early releases. I do not know whether MPLab X can backstep. That is certainly not essential, but there have been times it would have been helpful.

Yeah, many users will stick to MPLab, I guess. But I think there are users out there (like me) who prefer working on the commandline instead of downloading and installing gigabytes of data. Even if there is only one user who would use it, the work would have been worth it.

Didn't Microchip planned to include AVR Simulation to MPLab X ? Is it already supported ?

 

Didn't Microchip planned to include AVR Simulation to MPLab X ? Is it already supported ?

I have read that, but as a non-user, I cannot confirm.

I have no objection to using a command line. I use an older version (7.x) of Eagle for PCB's. Not only do I prefer the original GUI, I use the command line too. If given the choice between icons, keyboard shortcuts, and command line, I would take the latter two any day to icons. Drop-downs with words are also OK, particularly if I have been away from a program for awhile.

 

I've written simulators for PPC, TMS320C28, Blackfin, PIC, and SAMA5D2. But my first one was AVR (ATmega8, 16, 32, 128). Command line only, no GUI. I checked my AVR code and there appear to be about 136 instructions, so I'd say you should implement more of them. Of course compilers only emit a subset so those are the important ones, you can always implement others when needed. My ARM simulator implements about 350 but there are more, however using two compilers I appear to have covered most or all necessary.

Your comments for RET don't look right to me, the value from the stack isn't an offset, is it?

The best way to improve your simulator is to use it. Compile examples and run them and see if it works. Rig up UART communication with your PC keyboard so you can interact with the sim. As an example I set out to use my AVR simulator to test some standard C functions (e.g. strtod); I wrote test cases to cover each instruction in the Atmel supplied library and ended up finding a bug in their implementation, which I reported.

As I recall implementing the timers took a lot of effort, supporting all the various modes for each model of AVR. It is also useful to be able to schedule interrupts, one shot or cyclic.

 

I've written simulators for PPC, TMS320C28, Blackfin, PIC, and SAMA5D2. But my first one was AVR (ATmega8, 16, 32, 128). Command line only, no GUI. I checked my AVR code and there appear to be about 136 instructions, so I'd say you should implement more of them. Of course compilers only emit a subset so those are the important ones, you can always implement others when needed. My ARM simulator implements about 350 but there are more, however using two compilers I appear to have covered most or all necessary.

Your comments for RET don't look right to me, the value from the stack isn't an offset, is it?

The best way to improve your simulator is to use it. Compile examples and run them and see if it works. Rig up UART communication with your PC keyboard so you can interact with the sim. As an example I set out to use my AVR simulator to test some standard C functions (e.g. strtod); I wrote test cases to cover each instruction in the Atmel supplied library and ended up finding a bug in their implementation, which I reported.

As I recall implementing the timers took a lot of effort, supporting all the various modes for each model of AVR. It is also useful to be able to schedule interrupts, one shot or cyclic.

Thank you for replying.

Oops, yeah you are right it is not an Offset but a fix address. Thanks for that, I will fix the comment.

 

Update:

- Refactor
- Added Syntax Highlight for disassembled hex files

 

Rewritten in C

• Peripheral: Timer0 (8-bit) is now supported.
  • Supported Prescaling: 1/8/64/256/1024
  • Supported Mode: Normal Mode
  • Currently not supported: PWM and external clock select
• Timer interrupts are now available.
• Added new assembly instructions:
  • lpm(R0) (load program memory)
  • lpm(Z) (load program memory)
  • call (32-bit call)
  • las (load and set byte in data space)
  • lac (load and clear byte in data space)
  • fmul (fractional multiply unsigned)
  • reti (return from interrupt)
• Bug fix for the preprocessor
• Skip instructions are now compatible with 32-bit opcode
• Jumps, skips, etc. are now able to wrap around FLASH memory
• Refactored System class (Core / Peripherals)
• Seperate IO space class
• IRQ Handler
• Now supporting ~93 Instructions

 

Update (v.0.3.0)

• Supporting all 131 assembly instructions

Update (v.0.4.0)

• Added EEPROM peripheral module
• cycle accurate simulation of EEPROM
• EEPROM Interrupts (ERDY)
• Read/Write (atomic, erase) supported

• Now supporting the ATmega328(P)

Update (v.0.5.0)

• Reached 17 MHz execution speed. It is possible to simulate default Arduino in realtime

1. Added Analyzer Core Module for static code analysis
2. Future Analyzer submodules include:

1.) Function analysis (callers, args, etc.)
2.) SFR analysis (replace dataspace address with its actual register name)
3.) ...