Join us in two weeks for another live chat - on the care and feeding of watchdogs.
Thursday, November 29, 2:00 p.m. ET -- The role of watchdogs -- The watchdog timer is a time-honored mechanism for ensuring that an MCU-based design does not lock up as the result of a software glitch. But is a watchdog more problem than solution? Should it be internal or external to the MCU? How do you prevent it from falsely triggering, or perhaps worse, not triggering when it should? Come talk about your ideas and experiences with watchdogs.
Well, thanks all for joining in. Funny, I thought this might be a hot topic for the community. But not too many takers. Next month I'll have to try a different day and or time for these chats.
As far as I can tell, JTAG is a mess of a "standard" too. It looks like there are almost as many variations of pinout as there are users of the system. Based on a little research, it looks like the programming for test mode might vary as well.
Rich - I've never done that. We trried to offer that type of JTAG testing service where I work, but no one ever took us up on it. I'm not sure if it's used that way much at all.
That makes more sense. I was trying to wrap my head around how to do that inside of the chip. I haven't done what you're talking about, but I suppose it's not that different than, say, monitoring current draw and changing a PWM setting based on the results. I have done that.
duane, I was thinking of monitoring signals on the board, not inside the chip (hard to access, aren't they?) but like looking at, say, an I2C to make sure it has the right shape and all.
when waiting (in software) for some external event (like a slow external peripheral e.g. LCD display) add a timeout so that the wait doesn't become infinite. Additionally add some means of resetting the external device.
Bitbucket - PIC processors often have the ability to leave a peripheral on while the rest of the MCU is sleeping. I would expect that others can do that too. I haven't used that feature but I know that they can drive interrupts to wake the system.
My main problem with internal monitoring is that when testing low power modes sometimes the monitoring is turned off. Can take a while to figure out how to override it (if it is possible. Sometimes it isn't). Anyone know of any tricks for low power mode debug?
when talking with Scope Junction I speculated on the idea of using built-in ADCs as a poor man's oscilloscope to monitor key signals inside a design. Anyone using built-in signal monitoring in their designs?
I made the comment there as well- the PSoC is the ultimate device to allow internal access during development, but I promise to stop with PSoC now.
I am working oon something right now though that uses a crystal. I haven't been able to find a oscilator module is the right form factor that will operate at 3.3 and 5 volts. Crystals don't care that much.
when talking with Scope Junction I speculated on the idea of using built-in ADCs as a poor man's oscilloscope to monitor key signals inside a design. Anyone using built-in signal monitoring in their designs?
I usually try to use oscilator modules these days. It only takes one I/O pin and is very stable. Usually the cost isn't that much more and with surface mount packages, the module can take less board real estate.
it was just a thought. I wonder if the approach would even have any practical application.
The PSoC allows for teh ultimate in reconfigurabilty. In one Modbus application, I overwrote the UART (IIR) in order to use the internal CRC generator for the CRC, and then re-initiated to UART for the next message.
Ad, muxing isnt quite what I had in mind. I was thinking that the I/O pins would carry different functions. Maybe like a having an I2C port that became a USB port when you plugged in a cable (so you could download a program) then went back to being I2C for internal communications when the USB cable was gone. would save a port.
Rich - What about a case where you need to use several different communications standards, but don't have enough pins. Say share an SPI bus with RS232. That would be a case where dynamically changing the pin functions could come in hand.
it was just a thought. I wonder if the approach would even have any practical application.
I have had a single UART driving 4 different micros- since only one was being accessed at any give time, I muxed the UART TX & RX to speak to each in turn.
AD - on one of my newest robot boards - the design is done but I haven't sent it out to fab yet - I have four LEDs on board. I dodn't have enough spare pins, so the LEDs share I/O with a couple of pins that I have on the boad for connecting sensors and things. I put a Mosfet between the LEDs and ground so I can use them for debugging or take them out of the circuit if I want to use those connections for peripheral I/O.
AD - That would be nice. Usually PIC processors have a few peripherals that can be switch between two pins, but that's really not enough to help. I try to make sure my spare I/O can be digital or analog, but with small pin count devices, that's not always possible.
That way I can just plug an LED or something into it and I can reference against eiother power or ground.
Actually, I always have and LED on the board, whether it is visible to the user or not. It is great in bringing up the system with the start of development being to flash the LED. Afterwards the flash rate etc. can be used for status etc.
Another thing I've found handy is to keep a clock out pin accessible
The nice thing with a PSoC processor is that the internals are all configurable. So you can start the project bringing all the internal signals out to pins (including analog signals after interanl amplification) and measure them. Once you are satisfied you can then change the configuration back.
AD - I always try to run at least one pin, more if possible, to a set of three 0.10" pitch headers. I pot power, ground and signal on it. That way I can just plug an LED or something into it and I can reference against eiother power or ground.
Test points. good reminder AD. don't forget to include a ground reference point, especially near analog signals. And space them so that your probe can actually get in there.
wouldn't it toggle awfully fast? and why two pins? to give a 4-state code indicating location?
It would only toggle when desired. I often would set the pin at the start of a process and clear it at the end. Two pins for two supposedly independent events. The more the merrier. The only problem today is making a connection to those @#$% tiny pins! Test points as another good hint.
Another thing I've found handy is to keep a clock out pin accessible. PICF processors let you attach the system clock to an I/O pin and you can, via configuration bits, turn this off and on. I've had a few cases where being able to see the system clock has helped me run down problems.
I haven't had it happen in quite a few years, but I have had a few cases where just switching to release mode with all of the optimizations on would cause something to crash. I would have to put in little debug cose snippets of my own at various places to try and humt the problem down.
Since the are no others here, I may as well add the obvious tip- leave at least 2 pins available to allow to software to toggle so that you can track where the execution is. Also very handy in measuring exectuion times and relative occurrences of events.
Sometimes I don't use my outputs as outputs (where I haven't spare pins), but as indicators as described above, until the design has progressed up to a more defined point.
I suggested debugging first without optimizations (to get the flow and logic right) then turning them on. That way you would know that any problems cropping up were the result of the optimization, which seems like it would make it easier to track down. Opinions?
Rich - I would agree eith that. I have had a few cases in the past were the code worked perfectly when in debug mode but broke in release mode. That's tough to match up and hunt down.
In a series of exchanges with northstar, he pointed out how difficult it is to correlate debug info with the source code when compiler optimizations are in effect. Others seeing that?
AD - I think your suggestion is very good practice. I'm mostly the only one using my boards so I have complete control over how it;s used. That makes it easier to keep in line. If I were realeasin my designs to the wild, I'd most likely follow your advice.
do folks collect up a whole slew of bug fixes before recompiling, or can you do them fast enough to do one at a time?
Once again, not any more. The recompile is much, much faster. Also i find that the emulators/debuggers are not as versatile to allow simple code changes and also changing the PC to try out a small portion of code.
Rich - yes. The programming pins still work in that case. I just look at the design to make sure that programming won't mess with anything else and nothing else will mess with programming. If I don't need the pins, though, I'll just dedicate them to programming.
I like to make sure that when the programmer is hooked up, nothing but the MCU get any power or signal.
ok, so the programming pins do double duty as extra I/O, and the diodes ensure you can still use them for programming even after the board is assembled, right?
I still add a cautionary note- YMMV. Try it out before comitting.
ok, so the programming pins do double duty as extra I/O, and the diodes ensure you can still use them for programming even after the board is assembled, right?
I do recall doing that, but recently not. Partly because I am out of touch with the Assembly language of the devices, and there is no in-line compiler. Also the recompile is so much faster, that it is unnecessary.
Antideluvian - Re youf commen from yeterday: I often have the programming pins (clock and data, not the high voltage programming line) form my PIC processors available for I/O. I just don't have anything perminantly attached untless it's isolated with a schottky diode or Mosfet switch.
It's been a long while since I did any real design, so my suggestions may well be out of date. But I used to put patches in assembly code (via jump to the patch) during debugging just to avoid the delays of recompiling. Folks still do that?
I am not sure if I will make it tomorrow, so here is my tip:
Some micros allow you to use the in circuit programming pins as I/O. This should be approached with some caution
Rule 1: if at all possible, only use the programming pins for programming only
If you must use them-
Rule 2: Try to stay away from using the I/O as inputs. The circuitry that drives the input may be low impedance and may affect the programming pulses when you are trying to program the device. I have even seen a simple 100K pullup prevent successful programming.
Rule 3: When using the pin as an output consider what the output is driving since the programming pulse can activate that device. I was driving a relay and programming the micro resulted in many thousands of activations of the relay, thereby potentially shortening its life.
Join with other members of the MCC community to share design tips live. Come ask for help, offer suggestions, and generally trade ideas with fellow MCC enthusiasts. Because it's live, you can dig for details without having to wait for dueling emails.
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
