Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About MarkL

  • Rank
  1. This is not quite as it should be, another one for the improvements list Regards Dave Perhaps it's an idea to color the depth's which MIGHT be used by the interrupt with another color (blue?). Then you can easily see which functions might be at risk and need attention. E.g. for PIC16: Main hw: 9 Interrupt hw: 2 Level 7 and 8: Blue (or another color) Level 9 and deeper: Red Regards, Mark
  2. Raghunathan, You didn't mention if you used a debugger. When you use the ICD2 you must always include the icd2.h header: #include <system.h> #include <icd2.h> The compiler then protects the file registers used by the icd2 firmware. This might explain your unexpected changes in values. /Mark
  3. It would be very useful to be able to address individual struct members with the inline assember. This is especially useful in combination with macro's (e.g. MAKESHORT) Here is a (fictive) example of how it could work: struct point { short x; short y; } struct point pnt; . . MAKESHORT(pnt.y, lobyte, hibyte); . . There are several workarounds to the above but they all compromise the optimization or maintainability.
  4. Any news on this bug report? This bug is real and has nothing to do with my other report which also involves Timer2.
  5. Well, even if I am not supposed to do that (please tell me why!) the ide should not crash. I am not sure what you mean by 'load a garbage value like 0xFF'. It is a different bug report, and the other tmr2 problem is not solved. <{POST_SNAPBACK}>
  6. Load a PIC18F2520 project (I did not check other processors) - Start de Debugger - In the Register Bar: For tmr2 select: Add Watchpoint to 'TMR2' - In the Watch Bar: Add: 'tmr2' - Change the value of tmr2 in Register- or Watch bar and press enter - Press F11 to start/continue debugging Now the IDE.exe Crashes with an error: The memory could not be 'read'
  7. The PIC18F2520 Debugger Timer2 is not working, it always stays 0. The PIC16 debugger works correctly. This is the timer2 initialization I used (any value will do as long as TMR2ON=1): pr2 = 0x1C; t2con = 0x04; The identical source DOES work on real hardware. I have confirmed this with MPLAB and ICD2 where I can see register tmr2 correctly incrementing.
  8. The numbers are the amount hardware stack that will be used, this is in addition to that which is required to get to the interrupt routine. Do I understand correctly that -swcs 6 2 can use 9 (6+2+1) hardware stack positions? Than this still can cause call stack overflow! Please make this clear in the documentation, or change the example in the documentation to -swcs 6 1 to pointout this behaviour. Thanks, /Mark
  9. Hello, We have a project that is quite heavy on the interrupt call stack (16F876A). The linker gives the following warning: ------------------- Building CASM file Serious Warning: Call stack usage exceeds:8! Call Stack Usage Report ======================= main and Task(s): hw used:6, exceeded by:0 interrupt: hw used:6, exceeded by:0 ------------------- We tried to use the linker option: -swcs 6 2 to solve the stack problem. All warnings are gone, but we can definitely see in the generated .lst file that ONLY the first two calls in the interrupt tree a
  • Create New...