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.
All,
I am trying to track down a problem of some code that was written by an 'overseas' 3rd party (I will be nice and not state the country of origin).
This code uses a single timer set at a 1mS interrupt rate in order to determine if the SPI is still communicating externally with it's master. If no communications are detected the timer resets the SPI port, clears the interrupt, and jumps to the reset vector. The problem is: the SPI port remains dead until a power cycle is accomplished.
The obvious fix is to use the watchdog (which is what I will eventually do), but I would like to understand the why of why this does not work (yes, bad coding practice is the real reason)...
Since the code jumps to the reset vector this is what I have been able to analyze:
(1) Since this is not a true reset (ie: via watchdog) all hardware registers are not reset - problem potential here. (2) The jump to the reset vector was accomplished while in supervisor mode, so the privleged registers (ie: SP,etc) can be written. (3) The timer interrupt was cleared prior to making the jump to the reset vector, so all interrupts are still enabled. (4) Since this is not a true reset, all resident code can still execute (ie: interrupt handlers). (5) The startup code will reset all initialized data, registers, etc prior to jumping to program main(), effectively returning data to a power up state.
One reason I can currently come up with as to why the SPI is never functional after this occurs is that maybe an interrupt occurs while in the startup code (clearing a tracking variable or resetting the processor registers). But the interrupt would also inhibit the startup code until it was serviced. This potential cause is (probably) not the only reason for this issue, and why I am asking for your input(s).
Unfortunately, this board has no JTAG to connect so stepping through the code is not an option. I could write to the serial port - if it was connected, but it isnt. Right now I am trying to analyze my way through this code before using a 'hammer' approach to solving this problem.
What else am I missing in this analysis? Thanks.
Ok, so your position is that the onus to understanding a weakly written document is solely on the readers of that document - not the writer(s)?
Wow. All I can say in response to that is - I agree we disagree.
onus to understanding a weakly written document is solely on the readers of that document - not the writer(s)?
No. The onus on the readers is to actually prove that the document is weakly written before complaining about it. The onus on the writers is to amend it if it was proven to be defective. ISO has the Defect Report mechanism for that.
The onus on the readers is to actually prove that the document is weakly written before complaining about it.
Um. THAT was the whole point of the link Per included in his response. Did you read it? They documented a 96% failure rate using different programs and multiple compilers. They (the readers - specifically Utah CS) have done that part.
The onus on the readers is to actually prove that the document is weakly written before complaining about it...ISO has the Defect Report mechanism for that.
Um. THAT was the whole point of the link Per included in his response. Did you read it? They documented a 96% failure rate using different programs and multiple compilers.
You did not understand. As far as I understand it, Hens-Bernhard is referring to the razor-sharp language of the standard. You are referring to some article that tested implementations of it.
Tamir,
Please clarify what you mean by razor-sharp language. I read the specification as a typical technical standards document.
I personally do not see the 'legalese' that was mentioned within the specification to any great degree, but I do see the attempt to be a generic as possible. This in itself creates is the issue I believe leads to potential implementation problems.
For example, if you read lets say the description on how the 'for' loop should be handled/processed - it is quite clear to the reader (at least me) as to how it should function. However I don't see the same clarity with the volatile keyword implementation.