| View previous topic :: View next topic |
| Author |
Message |
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
 Posted: Mon Nov 23, 2015 10:09 am |
 |
|
I have updated the inline assembly to follow the listing in the data sheet:
| Code: | #ASM
MOVF _a_lo,W ; Set-up address to write to
MOVWF EEADR
MOVF _a_hi,W
MOVWF EEADRH
MOVF _a_lo,W ; Set-up address to write to
MOVWF EEADR
MOVF _ee_data,W ; Set-up data to write
MOVWF EEDATA
BCF EECON1,7 ; Point to Data EEPROM Memory
BCF EECON1,6 ; Access EEPROM
BSF EECON1,2 ; Enable EEPROM Write
BCF INTCON,7 ; Disable interrupts globally
MOVLW 0x55 ; The next four lines are required to allow the write
MOVWF EECON2
MOVLW 0xAA
MOVWF EECON2
BSF EECON1,1 ; Set WR bit to begin write
BTFSC EECON1,1 ; Wait for write to complete GOTO $-2
BSF INTCON,7 ; Enable interrupts globally
BCF EECON1,2 ; Disable EEPROM Write
#ENDASM |
But... I am still having the issue.
I did a little more investigation and based on something I noticed, I have a question. Is there a limit to the number of functions that can be defined? I have 72 functions, including main and the interrupt service routine.
When I remove the small function that I added for this original small change, the problem goes away. No underflow. But... When I add yet another function, completely empty, unused and not called anywhere, there are no issues. I remove the unused function and the problem returns. I also removed the small function I originally added, then added the empty function and the problem exists.
This just doesn't make any sense. How can adding a function or having a certain number of functions cause problems like this? Any ideas?
Thank you! |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9142
Location: Greensville,Ontario
|
|
| Posted: Mon Nov 23, 2015 10:18 am |
|
|
hmm.. wild guess...
maybe it's not the qty but the order they are coded ?
it's the classic 'out of ROM' error so maybe, just maybe the compiler has a subtle quirk ??
heck, nothing to lose, just copy the program, cut and paste functions a bit differently and see what happens.
IF it still fails, you've eliminated one possibility...
Jay |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Mon Nov 23, 2015 10:36 am |
|
|
I had neglected to mention it, but I did change the order of a few of the functions with no change.
But again, pulling at straws and digging through assembly in the lst file, I found this:
| Code: | 04D0C: BRA 4DBC
.................... case 1: // IN INSP? Y/N
.................... case 5: // AT DOWN LIMIT Y/N
.................... case 7: // AT FLR XX Y/N
.................... case 11: // AT UP LIMIT Y/N
.................... case 12: // VHC-102? Y/N
.................... if(current_lcd_line1[15]==0x20){ // Blank
04D0E: MOVLB 3
04D10: MOVF x78,W
04D12: SUBLW 20
04D14: BTFSS FD8.2
04D16: GOTO 2E6C
.................... if(setup_var)
04D1A: MOVLB 4
04D1C: MOVF x80,F
04D1E: BZ 4D28
.................... future_lcd_line1[15] = "Y"; |
The snippet above is roughly where I suspect things are going off into the weeds. I'm concerned about the GOTO 2E6C. When I look for this address, it is in a completely different function, 5000 lines away.
I'm wondering if there is a bug in the compiler that obviously doesn't show up all the time, but occurs when there are several case statements all for the same code?
In the normal "Failing" scenario, but duplicating the case code for all 5 cases, the problem seems to go away.
Is this a known problem? Too many cases? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Mon Nov 23, 2015 10:40 am |
|
|
Try this:
Isolate other cases, then have a default: case that covers your existing case 1, 5, 7, 11, 12. |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Mon Nov 23, 2015 10:59 am |
|
|
| newguy wrote: | Try this:
Isolate other cases, then have a default: case that covers your existing case 1, 5, 7, 11, 12. |
Just tried that and that also had issues... the GOTO (to the same address) moved to another group of cases that I used to try to isolate so the group of 5 could be the default... But the GOTO was NOT in the default.
So... instead of duplicating the code for each case statement, I created a small function to do what it should be doing and called that. That saw the same issue, but I noticed this:
| Code: |
04D46: BRA 4DC8
.................... case 1: // IN INSP? Y/N
.................... case 5: // AT DOWN LIMIT Y/N
.................... case 7: // AT FLR XX Y/N
.................... case 11: // AT UP LIMIT Y/N
.................... case 12: // VHC-102? Y/N
.................... setYN();
04D48: GOTO 3D7A
.................... break;
04D4C: MOVLB 4
04D4E: BRA 4DC8
.................... case 8: // Trim Floor
.................... if(current_lcd_line1[2]==0x20){ // Blank |
Notice that instead a CALL, its getting a GOTO. Why? Is CALL only used when there are parameters to pass, otherwise GOTO is used? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Mon Nov 23, 2015 11:15 am |
|
|
| Instead of 4.135 do you have 4.141 to try? |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Mon Nov 23, 2015 11:17 am |
|
|
| newguy wrote: | | Instead of 4.135 do you have 4.141 to try? |
Unfortunately I don't... :(
I tried to find a change log for the 4.xxx compilers but I could only find it for the 5.xxx compilers. Do you know of something that was fixed? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Mon Nov 23, 2015 12:00 pm |
|
|
No, just that it seems to be obvious that it's the compiler's fault, so logical thing to do would be to try a different version.
Contact CCS. They may take pity on you and send you a version that works. Send them a zip file with your project and detailed notes regarding the problem. It may be something that they fixed a long time ago or it may be part of a problem that still exists to this day. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19278
|
|
| Posted: Mon Nov 23, 2015 12:28 pm |
|
|
| Have to agree with Newguy. 4.135, was never considered a very 'good' release. They had a batch of problems around this time, which were often better in slightly earlier releases like 4.118. If you have another release, even an older one, worth seeing it things change.... |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Mon Nov 23, 2015 4:12 pm |
|
|
Well... I did get someone with v5.033 of the CCS Compiler to compile the questionable code for me. The problem went away and the assembly looks fine.
So, I think I can chalk this up to a compiler issue... although the workaround is just wasting space I don't have to spare. :(
Does anyone have a change log for version 4.xxx of the compiler? I'd like to go through all of the versions beyond 4.135 to see if there is anything else major that I'm missing. This project has been using this version for 3 years, and is wrapping up shortly. Moving to a dsPIC30F6015 using XC16. So updating the compiler probably won't happen. But I'd prefer not to waste another week trying to track down another compiler issue like this.
Thanks! |
|
|
Sam_40
Joined: 07 Jan 2015
Posts: 127
|
|
| Posted: Mon Nov 23, 2015 9:34 pm |
|
|
Is that an elevator controller project  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19278
|
|
| Posted: Tue Nov 24, 2015 3:09 am |
|
|
Unfortunately 'comprehensive' change data is something that CCS are poor at. They release a compiler, with a 'one line' change detail, and only after using it, does it become obvious that they have actually changed dozens of things.
There current change log, only goes back to the first official V5 release, and I don't think I've kept an old version. However one of the 'go back' engines, ought to be able to give you the V4 log. |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Tue Nov 24, 2015 7:44 am |
|
|
| Sam_40 wrote: | | Is that an elevator controller project |
Yes. Yes it is. :D |
|
|
terryopie
Joined: 13 Nov 2015
Posts: 13
|
|
| Posted: Tue Nov 24, 2015 7:52 am |
|
|
| Ttelmah wrote: | Unfortunately 'comprehensive' change data is something that CCS are poor at. They release a compiler, with a 'one line' change detail, and only after using it, does it become obvious that they have actually changed dozens of things.
There current change log, only goes back to the first official V5 release, and I don't think I've kept an old version. However one of the 'go back' engines, ought to be able to give you the V4 log. |
Good Call... Version 4.xxx change log found here:
https://web.archive.org/web/20130414022456/http://www.ccsinfo.com/devices.php?page=versioninfo
Unfortunately nothing sounds like it is related to this. But I do have my workaround, to duplicate the code for each of the cases. Not the way I like to fix things, but better than the alternative.
Thanks for everyone's help!! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
