8051 Coding and Debugging
by Olaf Pfeiffer, ESAcademy
based on the article "Real-Time 8051 Systems - An Overview", by Mike Beach, Hitex UK
Using assembly and sporadic status messages sent to the serial port to develop and debug an 8051 based application is not exactly "state-of-the-art". This article shows some of the benefits engineers get by using the right tools.
[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]
Testing Real Time 8051 C Systems - in LARGE memory model
Depending on the 8051 derivative and in-circuit emulation system choosen, on-the-fly access to internal memory areas such as SFR (Special Function Registers) or internal RAM will be limited. Some derivatives can be set into an emulation mode, where some pins are multiplexed and provide the in-circuit emulator with information about the internally accessed memory. While running, on-the-fly monitoring of internal variables is possible in real-time with such systems. Unfortunately, this feature is not available on "regular" 8051 derivatives.
However, with the previously stated testing problems and memory model points in mind, here is a solution to the real-time debugging problem of accessing internal memory on 8051 systems on-the-fly.
When a module or function is first being coded up, it needs to be compiled using the LARGE model, regardless of the final model to be used - normally determined by the hardware design. This has the effect of pushing all the variables into external RAM. During the debugging phase, the variables will remain in external RAM. Assuming that the compiler will produce code of identical functionality, regardless of model used, the programmer is left in the happy position of having all the variables and parameters of the new code sitting in external RAM rather than buried within the on-chip RAM.
The debugging via an in-circuit emulator is done at C source level, so that the user will single-step C lines or trace lines of C and will basically only view the program in terms of the C source lines originally created using his text editor. Essentially, just the logic of the program is actually being tested here, not the way that the 8051 is being driven by the compiler's opcodes.
As has been said, many 8051 systems have no external RAM, its all on-chip. However, if external code memory is used, port 0 and 2 are available as address and data bus. Having program variables located in external RAM therefore may appear unwise. However, using the in-circuit emulator's own memory, this absent RAM can be easily created. The program will therefore run using RAM within the emulator. Even though this external area is not actually part of the final design, providing the emulator is attached, the RAM is available and any LARGE/COMPACT model C programs can make use of it and run correctly.
Ultimately, the whole point of doing this is that the high-end in-circuit emulators will actually let you recover the values of variables located in external RAM, in real time. High-end in-circuit emulators also use dual-ported memory: the RAM mapped into the data space is dual-ported. This means that the 8051 can access the RAM, and in between cycles, the emulator's own hardware can get in and recover specific variables. Once extracted from the 8051 system, their values can either be reported to the user on the controlling PC screen, or directed into the emulator's trace buffer - it doesn't really matter which.
In effect what we have got now is the ability to recover C variables or program variables in real time "on the fly", using the real 8051 hardware. The only respect in which it differs from the proper hardware is that it has got the in-circuit emulator supplying the external RAM, where no RAM chip position actually exists on the board.
[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]
© ESAcademy, 2001
All materials
provided 'as is'
see Disclaimer