8051 on-chip debugging

In message , Schueler writes

This is because most MCU don't have on chip debugging capabilities. Over the last 5 -10 years JTAG has become more common. The 8051 family which is much older does not have it on the majority of parts.

What sort of on chip debugging are you looking for? The Atmel and NXP parts have on chip debug capability when used with an Ice (they use the Hooks and Enhanced Hooks system that does nto require a bondout part)

Others such as Sylabs do have JTAG.

Had you asked last month I had two 8061 ICE to give away (a Nohau and a Hitex) but they have gone now. Might be worth a punt on ebay for Emulators as both iSystem and Signum did Ice for the Dallas/Maxim part you are interested in.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Not easily/cheaply... see the other post.... Closest you will get is to write your own on board 'traps' that dump CPU status/important bits over the com port... or use simple diagnostic LEDs on spare port pins to identify various program points. It's a good processor :)

In message , TTman writes

Or..... If you are using the Keil compiler there is a Monitor system that works well (for a monitor :-)

This is a small piece of SW that will let you put in break points and single step the code on the board etc. It works though the serial port and talks to the Keil uVision simulator debugger.

There are several versions of the monitor depending on the chip and the memory.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Look a the Silabs parts, huge range of nice 8051 derivatives with on chip debug, cheap evaluation boards and debugging tools.

Michael Kellett

Which reminds me that there is a version of the NoICE monitor/debugger for the 8051. I use their ARM debugger with a Segger J-Link quite a lot and their MSP430 on those few occasions lately when I use a 430.

I have not used any of their offerings for the smaller processor families but NoICE has been around for a long time and their lead guy, John Hartman, is pretty fanatical about customer support. If it fits the OP's requirements, I'd definitely recommend it for consideration.

--
Rich Webb     Norfolk, VA

Looks interesting and something to consider if you can't get the Keil system.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Sorry for the repetition, but arguably the best 8 bit / 8051 devices around and by quite a wide margin. Sub $100 kits with quality toolchain that you can have running out of the box in less than 1 hour...

Regards,

Chris

[...]

I'm using it for the 9S08 (HC08 before) and I love it. Regarding the plain debugging functions, it's not far behind expensive tools like iSYSTEM winIDEA (which I'm using for Coldfire and 9S12).

Sadly John doesn't keep up with newer architectures like CM3.

Oliver

--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:

That might be coming. As I understand it, NoICE worked (teamed?) with Imagecraft as they (Imagecraft) developed their ARM7TDMI compiler. It is the default loader/debugger for that tool set and it supports Imagecraft's DBG format in addition to the more usual Elf/Dwarf files.

Imagecraft has been promising a CM3 compiler Real Soon Now and I would be surprised if they didn't choose to continue the relationship.

Disclaimer: No insider knowledge other than as a satisfied customer of both companies.

--
Rich Webb     Norfolk, VA

I'd skip any 8051 CPU. Move to ARM and save yourself a couple of headaches. Most ARM controllers have full debugging capabilities. But... you should realise you can't debug realtime processes anyway.

If you want to build a motor controller I'd first calculate the minimum and maximum PWM limits and hardcode these in software. The next step is to prototype the control loop using dummy input values. This can be done on a PC (and debug on a PC) since you are far better of writing complex pieces of software on a PC first and then compile them for your embedded platform.

There should be very little use for a debugger on microcontrollers. In other words: avoid having to use a debugger on a microcontroller.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Sorry, but what headaches ?. You can't equate modern gen risc core 8051 with the original intel devices. We built a 400Hz 3ph pwm inverter a couple of years ago with an si labs device and the s/w to drive it was well within the 4 k toolchain limit. The design included sine lookup table, voltage reg, current limit, over and undervoltage on input and inverter rails and a serial port for continuous stream status o/p. More than fast enough as well.

Arm are a great solution, but overkill for a small application, even though I do expect to standardise all dev around arm in due course, if poss, once all the infrastructure is in place. The arm toolchain is more complex to set up as well, unless you spend $K on commercial tools.

It's all about choosing the right tool for the job...

Regards,

Chris

Good approach. What I've seen a lot of lately is such competitive pricing for

32-bit microcontrollers that even though, yeah, they're overkill, you might as well get some of the extra creature comforts when they're just about free.

If you're paying engineers for their time, *good* commercial tools are well worth the money.

---Joel

It's a little way down the road, but there are obvious benefits in terms of common hardware and software libraries, not to mention the investment in time that is needed to become fluent in any new architecture.

8 bits can still be usefull though and modern 8051 class devices are running at 50-100 mips, so well able to keep up at much lower overall complexity. For the inverter, *everything* was written in C, including pwm interrupt handlers. Not a line of assembler in sight. They include a device with 24 bit a-d, which will be used in a current project. The key thing is that all the a-d, d-a and digital circuitry will be in one, low pin count package.

I guess an equivalent arm would be one of the Cortex M0 devices, but they don't have a a-d resolution.

No argument there, but it's not always easy to convince the client :-). Isn't the Keil toolchain for arm now around 4.5K ukp ?...

Regards,

Chris

I was thinking more like 3-4k, but yours is close enough (I'm kinda guesstimating the US$ to UKP exchange rate anyway and it's been a year or two since I looked...). However, I have found that at least with some software companies the rates are quite negotiable -- some years back we were able to get a few seats of IAR Studio for roughly half-price due to IAR's salesguy being (correctly) convinced that without such a price drop, he simply wasn't going to get the business period.

---Joel

Got a suggestion for an 8051 derivative with I2C, USB, and complete x51 ports? I have a project coming up that's essentially a rehash of a product that's been shipping for a decade. I need to add a bunch of crap to it but the boss wants to salvage the code in the original device (he doesn't trust programmers' schedules). If I were starting from a clean slate, I'd probably go with a Cortex M0 and throw the thing over the wall to the programmers. If it stays with an 8051 I might do the whole thing myself.

The current widget uses an Atmel 8051 but it's lacking I2C. I see the SiLabs parts have I2C but it appears they don't have full 8051 ports. SiLabs is interesting anyway. Thanks.

Headaches: no real stack (7 levels deep is not a stack and you must keep some locations free for interrupts) so the compiler must use overlays for function calls. 3 different memory areas. Very cumbersome (=slow) access to external memory with different instructions to get data from ROM or RAM. The real problem is that even though you program in C, you still can't really port the code due to all the pragmas, language extensions and the inability to really use pointers (which clutters your program because you'll make all variables global).

Which leads me to a point which IMHO is often overlooked. When deciding to use a platform you'll also invest time to write specific libraries for that platform. For some reason the decision never seems to include calculating the loss when moving to a different platform.

In the end the price counts and ARMs are (getting) cheaper due to the heavy competition.

YMMV. For ARM you can use GCC + Eclipse which is completely free. Since GCC and Eclipse support a very wide range of platforms and programming languages chances are that you don't need to learn a new toolchain if you already use GCC + Eclipse. Most compiler vendors have or are switching to Eclipse anyway.

I admit I have spend quite some time to understand GCC and binutils but since its the same for every platform the time is not wasted when moving to a different platform. Recently I had to write some firmware for a PIC controller. For that purpose I wrote a wrapper around the PIC C compiler so it behaves like GCC and so I could use Eclipse instead of Microchip's IDE.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

complex

What's the problem with "overkill", if it doesn't come at any extra cost ? The small ARM controllers are very easy to use.

ARM tool chain (free for small projects), trivial to set up:

SNIP

how do you arrive a 7 level stack on a 51 ???? Or did I misunderstand ?

We must have very different development styles - I won't use a micro without on chip debug if I can help it. I debug real-time systems on a regular basis and it's on real-time when hardware debug support really matters. Non real-time allows you to use software debugging tools like monitors or even print statements, when you hit a big problem on a real-time system then trace, hardware breakpoints etc etc come into their own.

Recently I've had to work with the AVR32 using IAR tools (rather limited hardware debug) and I really miss all the good debug stuff I've got used with Keil and ARM Cortex M3.

I do agree about skipping 8051 unless there is a very good reason to stay with it - even though the Silabs bits are nice I haven't done a new design with one for some time (in fact not since STM32F.... ARMs appeared).

Michael Kellett