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.
Since uVision4 was purchased and there are features I have not yet used I thought I'd try the included Logic Analyzer utility to get the hang of it. However, I have run into a couple of issues...
After the normal setup learning curve the Logic Analyzer starts running for approximately 3-5 secs before I get the Trace Status Bar error "HW Buffer Overrun" and the Analyzer shuts down.
After trying the suggestions at the Keil ULINK2 Users Guide for this error the only way (so far) I am able to monitor this variable is to NOT 'PC Sample' with the prescaler but rather use the 'Every R/W' instead.
Therein lies the rub...
This variable is constantly checked/tested as a conditional within the main loop (yes, it is foreground/background - not my choice). Because this is considered a 'read' when its in a conditional the HW Buffer Overrun error still occurs.
The only way Ive been able to overcome this is by creating two variables. A 'history' variable that is compared with the original and if they are unequal updating itself and then updating the second or 'debug' variable which is then monitored within the Logic Analyzer.
This is/seems-to-be more work than is necessary. Has anyone found a way around this issue? If so, please share...
The problem you are facing (HW Buffer Overrun) occurs when Logic Analyzer is used for debugging real Cortex-M HW via ULINK. It won't appear when using the simulator.
In order to track variables and show them in the Logic Analyzer it is necessary to trace memory writes to the selected location. Tracking memory reads is not required.
Cortex-M3 generates trace data for specified memory read/write. In earlier versions of the core it was not possible to specify that only write access should be traced. It automatically traced read and write accesses to the specified memory location. This limitation was removed in the latest Cortex-M3 revision 2 (r2p0) and now it is possible to specify also a write only access.
NXP LPC17xx and Atmel SAM3S devices are based on Cortex-M3 Rev2 while some older ST STM32F and TI Stellaris LM3S devices are based on earlier Cortex-M3 revisions.
So when using Cortex-M3 prior Rev2 in the situation which you have described (variable checked in main loop) trace will be generated not only for the required write access but also for all frequent read access and this will quickly cause an overflow. The only reasonable solution is an additional debug variable with write access only.
When using Cortex-M3 Rev2 this should not be a problem anymore and the unmodified code can be used.
Anyway using ULINK2 for trace is still limited due to the low trace bandwidth. In order to get full trace (including instruction trace) the much more powerful ULINKpro is required.
Robert,
Thank you for your clear and concise reply. Seems my solution was the only proper one for this revision of the chip.
Wondering (out loud) if the H/W guys know our boards are being populated with a non-r2 chip when one is now available? Hmmmm...
Thanks again.