We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I created and use an ASSERT macro to validate param's passed to func's, as well as the value of global var's used by ISR's, etc. I noticed that occasionally while debugging, an ASSERT would trigger for a global var used in my A/D ISR. Upon inspection, I confirmed that it was used in a very small number of locations, and there was no way it could be out of range as the ASSERT indicated. I did confirm that both the CLR_MEMORY and INIT_VARS build flags in my start167.a66 file were set to 1, but that shouldn't have mattered anyway since the var in question was init'd to a valid value just prior to enabling the A/D INT in my initialization func. I tried to duplicate the problem, but it did not appear to be repeatable enough for me to catch (while looking for it --- I was too impatient). However, it did happen every once in a while, and one of those times I noticed that the ASSERT triggered before my main() function was called, which meant the A/D INT was getting enabled before I enabled it, or so I thought. I now think that the problem is due to the fact that I'm using a [very slightly modified] canned MONITOR program in bootstrap load mode (the Phytec KC167CR sample), without pressing the RESET button on my pcb in between loads of new code, and therefore, once my code runs that enables the A/D INT, it stays enabled forever (since my code never disables it, unless the uC gets reset somehow). I did confirm that once my A/D INT was enabled, I could stop the debugger, remove the line of code that enabled the A/D INT, rebuild and reload the code, and the A/D INT remained enabled! I looked through the code in the Phytec MONITOR sample, trying to find the associated code, to see if I could modify it to negate all INT's (other than the one for the serial port that it needs), but to no avail. Is the "correct" solution to this problem to always make sure the uC gets reset prior to loading new code in BSL mode, or am I missing something?
Did you mean multi-word (this is a 16-bit architecture)...? Anyway, no, my ASSERT macro (when in debug mode) does an immediate disable of the global interrupt enable, puts all H/W into a safe state, displays a debug message on an LCD, and then hangs in an infinite loop. I have begun cycling power between loads of new code, leaving power off long enough to insure that the MONITOR program will get reloaded too. I can't imagine why the debugger wasn't designed to always reload the MONITOR, it doesn't take that long to do. If I could find a way to tweak the MONITOR to (1) prevent it from being able to reload code without 1st reloading the MONITOR, and (2) to cause it to disable all interrupt enables (that it didn't need itself) before enabling the global interrupt enable, I think that would solve this problem for me.
"Did you mean multi-word (this is a 16-bit architecture)...?" I would have if I'd realised you were using one of those modern new-fangled things. I know this makes me sound even more like a luddite, but it sounds like you've found one of the many reasons why I don't tend to use monitors, simulators or emulators. Stefan
I know this makes me sound even more like a luddite, but it sounds like you've found one of the many reasons why I don't tend to use monitors, simulators or emulators. The only 'debugging aids" I will use is a well known ICE and a well known scope. If I have to start using another ICE or scope I spend a few days 'debugging' a working project before using it for the purpose. As far as monitors, they change your project and are as such worthless for verification of a product. Simulators are exactly that, just consider the difference between simulated sex and the real thing. Erik
Well Erik, if I wouldn't have had so many problems with my (expensive (for me)) Nohau ICE for the C167 that relegated it virtually useless (for anything other than anchoring boats) I wouldn't be in this situation. I wish I could make my Nohau ICE work, but I had so many problems with it that I eventually just put it on the shelf to collect dust. What ICE do you use for the C16x? At least the KEIL debugger knows what complex var's are (like typedef'd structs) and lets you view them in an easy to understand form. That's another good thing about KEIL's debugger.
I use the Lauterbach Trace32-Fire emulator. Very expensive but worth every penny. -Walt
Well Erik, if I wouldn't have had so many problems with my (expensive (for me)) Nohau ICE for the C167 that relegated it virtually useless (for anything other than anchoring boats) I wouldn't be in this situation. I wish I could make my Nohau ICE work, but I had so many problems with it that I eventually just put it on the shelf to collect dust. it seems that Nohau users are either extremely happy or the exact opposite. Just like the reaction to fried liver. What ICE do you use for the C16x? I do not use the 16x, I use the XA with a Ceibo eb-xa (works well, lacks a bell and maybe a whistle, but can't be beat for price performance) msame for the EB-51 and EB-51x2 I use the Lauterbach Trace32-Fire emulator. Very expensive but worth every penny. Very expensive and, indeed very good. If you are in a situation where time matters muuuuuuuuuuuuuch more than money, that is the way to go. However, I still thinik that even with the stellar performance, it fails in the price/performance comparison. I think that maybe I could save 5-10 hours a year if I replaced my Ceibos with lauterbachs. Erik
Oh-well... thank God for my trusty HP54622D oscilloscope/logic analyzer, and for the 16-bit debug latch with the header for the logic analyzer designed & built on my pcb. At least I have some debug tools I can trust, that work extremely well too!