Hi, I am running UART solution on 8051. There is only UART interrupt handler and no other interrupts. All code runs in polling mode, having 4 TASK and using minimal OS (RTX)
There are two specific functions which randomly gets called sometimes. These functions are system initialisation functions and are not executed in any path during traffic test. so surely, there is corruption happening, which causes these functions to get called randomly.
I want to understand what are tools/methods to follow to find out root cause for such corruption symptoms. i would like to have suggestion for best way to debug this issue on 8051 platform.
Best Regards. Thanks for your time.
-Rajan Batra
White Pages says >65, so yes, but still younger than my dad, and a few decades my senior.
ARM is a clean and clever design, by a couple of really sharp dudes (at least formerly) from Cambridge. They know their stuff, and the tools, including the availability of Keil ones in the context here, make it a very good architecture to study, and an expanding sphere of use. Someone specializing in microprocessors would do well to study a lot of them, both RISC and CISC, but as an educational vessel the ARM is a good ship to start out on.
The 8051 is clever too, but it's role is diminishing, and awkwardly overloaded, to the point it's basically caretaker silicon for hardware that's orders of magnitude more complex. Most people doing SoC work would pick something else, for non caretaker / power management roles. Stand-alone processors are becoming more irrelevant.
there are places for every technology, and while I agree with you re "the teaching establishment" I would not use an ARM, but a 4-bitter for certain apps.
Just to clarify, I have developed many things using the ARM, so my 'defense' of the '51 is not due to me being "stuck in old technology" I just can not agree that "unconditianally the ARM" is a valid statement.
And I'm old
But are you as old as the great Erik Malund?
He's posted more comments on this site alone than most of us youngsters have had hot dinners.
Orbital Sciences might be using 40 year old rocket engines that were plastic wrapped in Siberia for decades, but I'm pretty sure they weren't using 8051 chips to complement them. And while NASA were scrounging up 8086 devices for the Shuttle program they stopped doing that.
There comes a time when the teaching establishment needs to teach microprocessors and assembly language using a clean 32-bit device with an orthogonal instruction set. In the late 70's, early 80's this would have been the 68K, but by the mid/late 80's its the ARM.
And I'm a guy who's coded on more microprocessor and SoC architectures than I've had birthdays. And I'm old. Believe me, if you have a solid grasp of one micro the others are all very similar, as are the concepts of assemblers, compilers, linkers and loaders.
Your options would depend on what "8051" we're talking about. ...... You could consider an ARM part with a richer debug environment. there are (e.g. SLabs) '51s with a "rich debug environment" the ARM/51 decision need not be on that base.
There are several jobs that still will get done better/faster/cheaper with a '51 than an ARM. On the other hand e.g. banking '51s is ridiculous with the availability of reasonably priced ARMs
Insufficiently large stack, stack auto/local variables accessed beyond bounds, or otherwise being corrupted?
Errant pointers, or other code, corrupting OS tables or control structures?
Your options would depend on what "8051" we're talking about. If you've got an EPROM device, then you'll want to add code to check stack usage, or memory corruption, and what routines are being run. This might permit you notice any commonality in the failure.
If you have external memory you could trace execution via a logic analyzer.
You could consider an ARM part with a richer debug environment. It's 2014, pretty close to being 2015
Hi, Any thoughts on it ?
Best Regards, -Rajan Batra
View all questions in Keil forum