Jump to content

chmotori

EstablishedMember
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About chmotori

  • Rank
    Newbrie
  1. Dave, I'm happy you already fixed this issue. Unfortunately, I'm stuck with my project since I cannot execute or debug the code. Have you an idea about when version 7.03 will be released? I recently bought a commercial licence for this new company I started to work with. I told my boss to buy this product because I already used it for a long time for non-commercial purposes, and I never had any problem. Now I cannot wait a month or two for the official release, I'm afraid I'll be fired before that time. Could you please build up a release candidate of the compiler? I'd appreciate it very much. Bye - Elpidio Scaroni
  2. Hello, I recently upgraded to BoostC++ version 7.02, but it didn't solve a problem I'm having since a long time. I'll try to explain the issue with my own words, but then it's better to compile the project attached, and take a look to the code generated by the compiler. The program I've written currently is about 11kwords, that is a 67% of tyhe total memory space of the PIC16F1938. Analyzing the machine code generated by the compiler, right at the start (Reset vector at address 0x0000), there's a jump that should take the cpu to the area in which all of the static variables are initialized. Instead of doing this, the GOTO instruction ends up in the middle of the code of a procedure, that is not even the main(). I investigated a bit to find the reason of this, and I saw the following: - the first instrucion at 0x0000 is a BSF 0xA, 0x3 (sets bit 3 into PCLATH) - the second instruction at 0x0001 is GOTO 0x294 The GOTO instruction, together with the value of PCLATH (which is 8), will take the PC to the address 0x0A94, which is in the middle of my code. The right place to jump to, sould have been 0x2a94. Seems like it was missing an additional instruction like BSF 0xA,0x5. This would have set PCLATH to 0x28. By manually forcing PCLATH to 0x28 (in debug mode with the ICD3), the code executes well, it goes through all of the static variables, and at last it reaches the begin of main(). Please advise if my interpretation of the bug is correct, and do the fix as soon as possible. If you can manage to build a trial version of the compiler by fixing this bug, I'd like to test it, I don't have the time to wait for an official release. Thank you - best regards, Elpidio Scaroni PIC16F1938BUG.zip
  3. Hi, with BoostC version 6.93, using the linker option -rt, the compilation summery reports the same amount both for available and used ROM memory, giving a (wrong) indication that 100% of available memory is being used. The project I'm working with is for PIC18F46K20, I turned on global optimization for the compiler (-O2), optimization for linker (-O1). With no -rt option for the linker, the summary reports: ROM available: 65536 bytes, used: 50308 bytes (76.8%), free: 15228 bytes (23.2%). When I add the option: -rt 0xF7FF, I get: ROM available: 50308 bytes, used: 50308 bytes (100.0%), free: 0 bytes (0.0%). Regards, Elpidio
  4. Hi, I don't know if it's a bug, but it's a bit annoying, that the boostC compiler (6.93RC2) only report a warning when i use the syntax: structVar->element where it's supposed to be: structVar.element since structVar is a struct variable, not a pointer to a struct. It's annoying especially because, when compiling ten or more files, the warnings are reported only at compile time, and are not summarized after the linker has finished. Regards, Elpidio
  5. Thanxs, in the meantime I did some further investigations... here is the disassembly listing of strlen library function: --- E:\Prg\SourceBoost\compiler\picantc\libc\string.c ------------------------------------------ 3272 6B95 CLRF 0x95, BANKED 3274 5194 MOVF 0x94, W, BANKED 3276 6EEA MOVWF 0xfea, ACCESS 3278 5193 MOVF 0x93, W, BANKED 327A 6EE9 MOVWF 0xfe9, ACCESS 327C 5195 MOVF 0x95, W, BANKED 327E 2B95 INCF 0x95, F, BANKED 3280 26E9 ADDWF 0xfe9, F, ACCESS 3282 50EE MOVF 0xfee, W, ACCESS 3284 6F96 MOVWF 0x96, BANKED 3286 5396 MOVF 0x96, F, BANKED 3288 E1F5 BNZ 0x3274 328A 52EF MOVF 0xfef, F, ACCESS <-- this is where I think the bug is! 328C E1F3 BNZ 0x3274 328E 0795 DECF 0x95, F, BANKED 3290 0012 RETURN 0 Explanation: at address 328A, reading the memory pointed by INDF0 returns the memory location right after the termination char of the string, since the FSR0H:L has been post-incremented by the instruction at address 3282. if, by chance, the byte after the termination is not null, the loop goes back to the start. Regards, Elpidio
  6. Hi, I'm compiling a project for PIC18F46K20, the string library function unsigned char strlen(const char *src) returns incorrect string length on some occasions. I tried to investigate to get more hints, but didn't understand how to replicate the bug consistently. It occurs for some strings, while it doesn't for some others. All strings are in ram, pointed by a char *variable. As far as I can see, the value of the pointer is correctly passed to the library function, but after that I lose control of what's happening inside.... Let me know if you want me to post my project (it's a big project, almost 50K). Elpidio Scaroni
  7. ok, sent. if you need further information, please send me an e-mail (in case I forget to get a look at the messages in the forum).
  8. no problem, as you said previously, if you have such a policy of non-disclosure, I can send the whole folder. Just confirm me I have to send it to support@sourceboost.com.
  9. I had the same problem with one of my projects. There was a function, optimized as inline by the compiler, and called from my ISR, which gave me the same error. I tried moving the project folder to a different place, and it compiled successfully. I tried with both shorter and longer path, it didn't matter, it always compiled successfully, except in the original folder. At last, I found a way to make it compile in the original folder: I got a static variabile declared within the function, it was enough to move it outside, to make it work. Compiler: BoostC version 6.70 release candidate Operating system: XP SP2 Device: PIC16F685 Please note: with compiler BoostC version 6.60 I had no such problem! hope I was helpful...
×
×
  • Create New...