Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Carnage

  • Rank
  1. I know is an old thread, but finally after 2 years, got all the code running fine on sourceboost and mplab. The problem was present on 6.90, 6.91 and 6.92 (not present on 6.89) so I stop upgrading, since 6.89 worked fine but not the new ones. This week I downloaded 6.97 and was happy to check that this problem is gone. Something that was messing up was finally out. Thanks guys
  2. Strange, let me check it again. You are right, it appears that was a debugger problem. BTW will SourceBoost get any hardware debugger?
  3. Pavel: Strange I have it attached on this post. Hope this help Thanks main.txt
  4. Pavel or Dave: Did you got the chance to check the problem I decrive above?
  5. I think this is a different issue. Hard to know whats going wrong here with only such a small snapshot of events. Looks like the code is entered with a bad pointer, where does that pointer value come from? Regards Dave Dave I made a new proyect and found the same isue here is the code (please note debug is on) The problem again is in the same function (SendData) Aparently the paramaters and the first local variable StoreMsg (or any variable that take the first place) ocupies the same memory space A pic of the new proyect same problem Thanks
  6. Dunno if I'm having the same problem here: I'm copying some struct data to be send via serial port, but the thing I was getting was wrong data. I checked all my code and it seems ok, So I started using MPLAB debugger to see what went wrong. Everything seems nice until a memcpy call, so I check the function again and finally realize the following: Here is an screenshot: As you can see both StoreMsg, and Data->Msg.Time share the same address.
  7. I Use AutoPicKit: C:\Archivos de programa\SourceBoost\AutoPicKit.exe %name%.hex It works great, mine it's been modified to look for PICkit2V2.exe on "C:\Archivos de programa\Microchip\PICkit 2 v2\" (spanish XP) Get it at: http://www.timothyweber.org/autopickit
  8. just answered myself, only a byte wide, not a word wide
  9. I'm making this bootloader that has a 4K reserved boot block. So the bootloader start at 0x0000, interrupt at 0x0008 and interruptlow at 0x0018. Ok so for the program to be load it all need to be started at 4K so add: -rb 4096 at the linker, for all the programs that will be loaded under this bootloader. The thing is that I know as the program start at 0x1000 the interrupt is at 0x1008 and the interrupt low at 0x1018. So I try adding the following DATA in the FLASH of the bootloader to make this jump: #pragma DATA 0x000008, 0xEF04, 0xF008 #pragma DATA 0x000018, 0xEF0C, 0xF008 But
  10. Try this: 1) Ensure you have the correct library as part of the project, it needs to match the Novo RTOS header file use in the program. 2) Use the linker command line option -swcs to turn on software call stack used by Novo RTOS. I think you will find that you have #2 missing Regards Dave I have some other strange problem. The thing is that under MPLAB all my code works as it should. But under SourceBoost IDE it doesn’t. I didn't get this right until I started using MPLAB debugger, it was for a simple function (sprintf32) it was returning strange thing like 'N' when I asked
  11. Strange: I use both: if(test_bit(intcon,TMR0IF)) { //stuff intcon.TMR0IF = 0; } and if(intcon.TMR0IF) { //stuff intcon.TMR0IF = 0; } Both works ok, maybe your interrupts are bad.
  12. I have been using Novo for about a year now (really love it), but I'm wondering about one thing. In the main task all the example usually use only the yielding function: while (TRUE) { Sys_Yield(); } Could we use the main thread also for another task, say I have 3 task, and I need a new one, so the main would work for a new task. I'm asking this because I'm starting to get tight on RAM and ROM, but I need a new task, so maybe the main fuction could do that job Thanks
  13. Reynard, thanks for your help, that was exactly what I was looking for.
  14. Hello there: I have the following problem, I'm using a pic18LF6722 rev 0x00, and as the errata said I'm having problem when returning from interrupts, the solution they propose is to save again the values of status, bsr, wreg on the shadow regs, to do that in c it would be the following: void interrupt_branch( void ) { asm pop whatever ... ... return; } void interrupt(void) { asm call interrupt_branch,1 return; } with the call I save the real values on the shadow regs, and pop the return addrr, the problem is when I compile this it adds a lot of code: 27C0 CFEAF001 MOVFF FSR0H,
  15. First alloc supports max 127 bytes of allocation size (from BoostC help "void* alloc(unsigned char size) Dynamically allocate memory 'size' bytes long. Max size is 127 bytes..."). It'll be also helpful if you supply (simple) code that shows the problem and mention what target device you use. Regards, Pavel Pavel: Thanks for the answer, can't belive I didn't read that, change size to 127 and it works like charm Anyway here is the code, the target is PIC18LF6722 void LogFugawi(void) { FILE *GpsFile; FILE *WayPointFile; DWORD BytesWritten = 0; DWORD WayPointNum = 0; BYTE *Fugawi; BY
  • Create New...