Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ric355

  • Rank
  1. I finally got to the bottom of this problem. I tried to reproduce the fault with a small application but could not do so. I ended up purchasing an ICD2 and switching to MPLAB to debug it. When I started using MPLAB I began to get a warning dialog saying that the application may not work properly because the extended instruction configuration bit was set. Sure enough, checking the configuration bits revealed that this bit is indeed set. I ignored the message for a while as I hadn't realized quite what it was telling me, and on debugging I could clearly see that the file registers being af
  2. I just got MPLAB integration working but came across a gotcha that I thought I'd post up in case anyone else had the same issue. The problem I had was that a single file project could be compiled, linked, and debugged via ICD2 but a multi file project could not. The second source file in the project was being successfully compiled (.obj produced), but MPLAB then reported 'Build Failed' before even attempting to compile the third file. It turned out that the reason for this was that I had included files into the project from directories other than that in which the project file resides. Wh
  3. Can you supply a small but complete program that demonstrates the problem, preferably one that will run under the SourceBoost Debugger/simulator. Regards Dave Will post back later with something hopefully.
  4. From BoostC help: "Standard user functions are not thread-safe: their local variables are not saved when function execution gets interrupted by an interrupt. This can lead to very hard to trace errors. To prevent this pitfall, the linker does not allow to call a given function from both main() and interrupt threads. If you really need to use same function in both threads, you need to duplicate its code and assign a different name to the second copy." Regards, Pavel Yes, thanks, but since I had interrupts disabled (GIE=0) at the point the call to the function executes, I wouldn't ha
  5. Having played around a bit more with this, I think it may have been a problem with calling the same function from the main loop and the interrupt code. I haven't managed to prove it fully, and the place where I was calling it from in the main loop had GIE = 0, so interrupts should not have been firing, but having changed the software to eliminate this the problem seems to have gone away. Will post back if the issue re-surfaces.
  6. The following code fragment executes correctly in the debugger, but on the chip the output (to an LCD) implies that the int32 i has been corrupted. int32 i; float f; rd[0] = 1; rd[1] = 7; rd[2] = 5; rd[3] = 3; void calc_func() { i = rd[0]*1000+rd[1]*100+rd[2]*10+rd[3]; // i has value 1753. f = float32_from_int32(i); // after executing this line, i has value 1536. } In the debugger, i retains value 1753 throughout. However, when executing on the chip, after executing calc_func() the value of i (which is declared in the global co
  7. I have the following fragment of code, which is being executed as part of the interrupt routine; rd[digitindex]++; if (rd[digitindex] > 9) { rd[digitindex] = 0; } rd is global and defined as: char rd[4]; So each digit in the array goes from 0-9 and then wraps around to zero again. digitindex is always in the range 0-3. The code generated by the above is as follows: rd[digitindex]++; 2AC2 0E00 MOVLW HIGH(gbl_rd) 2AC4 6EEA MOVWF FSR0H 2AC6 0E48 MOVLW LOW(gbl_rd+D'0') 2AC8 6EE9 MOVWF FSR0L 2ACA 5065 MOVF gbl_digitindex, W 2ACC 26E9 ADD
  • Create New...