Proton BASIC Community

Hello again, I would appreciate a sharper set of eyes to help me determine what is "off" with the below code that is causing a "Frontend Loader has stopped working" message box to pop up whenever I try to compile it.  The logic seems fine to me, and I get no error codes except for the loader failed msg box mentioned above.  I am using an 8 pin PIC to generate high/low pulse chains at either 2 or 200 Hz rates depending on switch selections.  Am I implementing something weird, or is the code too long for the available flash?  I have not seen this flaw before.  Any suggestions?  I appreciate in advance any help you can offer.  Thanks,  Paul

;-------------------------------------------------------------------------------
;**** Added by Fuse Configurator ****
; Use the Fuse Configurator plug-in to change these settings

Device = 12F675

Config FOSC_INTRCIO, WDTE_OFF, PWRTE_OFF, MCLRE_OFF, BOREN_OFF, CP_OFF, CPD_OFF

;**** End of Fuse Configurator Settings ****
;-------------------------------------------------------------------------------
Xtal = 4
All_Digital = True

Setup:
TRISIO = %011000
Symbol RED = GPIO.0          'use CA RGB LED
Symbol GREEN = GPIO.1        'use CA RGB LED
Symbol BLUE = GPIO.2        'use CA RGB LED
Symbol ManualSw = GPIO.3    'state change
Symbol ModeSw = GPIO.4      'mode change
Symbol PulseOutPin = GPIO.5  'output pin

Dim slowcount As Byte
Dim ManualMem As Bit

High RED
High GREEN
High BLUE                    'all LED elements off

Main:
High RED
Low PulseOutPin
Low GREEN                    'set output low and light Grn
DelayMS 50
Checklow:
If ModeSw = 0 Then
  DelayMS 15
  If ModeSw = 0 Then
    GoSub ModeRelease        'if ModeSw pressed for >15mS, change to next mode
    ManualMem = 0
    GoTo FastPuls
  EndIf 
EndIf
If ManualSw = 1 Then GoTo Checklow
GoSub ManRelease            'if ManualSw is pressed, change state

HighEntry:
High GREEN
MHigh PulseOutPin
Low RED                      'set output high and light Red
DelayMS 50
Checkhigh:
If ModeSw = 0 Then
  DelayMS 15
  If ModeSw = 0 Then
    GoSub ModeRelease        'if ModeSw pressed for >15mS, change to next mode
    ManualMem = 1
    GoTo FastPuls
  EndIf 
EndIf
If ManualSw = 1 Then GoTo Checkhigh
GoSub ManRelease
ManualMem = 0
GoTo Main                    'return to previous state

FastPuls:
High RED
High GREEN
Low BLUE                    'light Blu LED
High PulseOutPin
DelayUS 2500
Low PulseOutPin
DelayUS 2500                'output 200 Hz pulse
If ModeSw = 1 Then
  GoTo FastPuls
Else
  DelayMS 15                 
  If ModeSw = 0 Then
    GoSub ModeRelease        'change to next mode if ModeSw is pressed     
    High BLUE
    GoTo SlowPuls
  EndIf   
EndIf
GoTo FastPuls                'otherwise continue fast pulses

SlowPuls:
High GREEN                 
High PulseOutPin            'high output and Red LED on
Low RED
For slowcount = 1 To 10
  If ModeSw = 0 Then
    DelayMS 15
    If ModeSw = 0 Then
      GoSub ModeRelease      'check at intervals for mode switch press
      If ManualMem = 0 Then
        GoTo Main
      Else
        GoTo HighEntry      'if pressed return to Main label and set either high or low
      EndIf   
    EndIf 
  EndIf 
  DelayMS 50
Next
High RED
Low PulseOutPin
Low GREEN                    'low output and Grn LED on
For slowcount = 1 To 10
  If ModeSw = 0 Then
    DelayMS 15
    If ModeSw = 0 Then
      GoSub ModeRelease      'check at intervals for mode switch press
      If ManualMem = 0 Then
        GoTo Main
      Else
        GoTo HighEntry      'if pressed return to Main label and set either high or low
      EndIf     
    EndIf
  EndIf 
  DelayMS 50
Next
GoTo SlowPuls                'return for more 2 Hz pulses
                                                                 
ModeRelease:
If ModeSw = 0 Then GoTo ModeRelease
ModeHiCheck:
DelayMS 15
If ModeSw = 0 Then GoTo ModeHiCheck  'if Mode switch released for >15mS then change Mode
Return

ManRelease:
If ManualSw = 0 Then GoTo ManRelease
ManHiCheck:
DelayMS 15
If ManualSw = 0 Then GoTo ManHiCheck  'if Manual switch released for >15mS then change state
Return

End


When I compile this I get the error:ERROR [Line 50]: Item 'MHigh' not found. With MHigh changed to High the program compiles.

An appended message:  I noticed a typo on the 2nd line under the HighEntry: label.  MHigh PulseOutPin was entered instead of High PulseOutPin.  After correction, this made no difference.  Apparently, whatever is triggering the error during the code scan is occurring before the syntax errors are checked, otherwise this would have been caught by the compiler and reported as an error.  Maybe this clue will help with tracking this problem down?  Thanks again.

Flosigud, I caught that also.  I was writing it up when you responded.  When I fixed the typo, I get the same problem.  I wonder if I am using an older version of the compiler?  Shouldn't cause an issue, but who knows?  Thanks.

Hey again, I am using IDE vers. 2.0.3.3, Loader vers. 1.0.3.1 and Compiler vers. 3.7.3.6   Too old?  Any known issues with these?

Too old, it compiles with the latest Positron. You should upgrade to v.4+ or stick to the old syntax and commands, but it would be hard to get any help there.

I can successfully compile other known good programs that target the PIC16F675, but not this one.  Curious?

Okay, Trastikata, I will try an upgrade (probably overdue anyway).  Thanks for the sanity check on the code.  Regards,  Paul

Hi,
Like most of us here we are on the newer version where the code compiles.
I cannot see any issue that looks wrong but if I were to be presented with a problem like that I would cut out most of the program and try to compile. Try just the code up to before the Main: label and see if that compiles.
If it does then add a subroutine etc (not concerned if the code will work or not, just trying to see if it will compile) and compile until it fails and hopefully it will get you nearer to where the problem is.

Regards,
Bob

The Julius Caesar approach?  Divide and conquer.  I like it.  I can comment out sections of the code to find the offending segment.  It's just that there were no code errors discovered during the process, just a statement that the loader barfed on me.  I had never experienced that issue before, so I thought I must have done something egregious, that would be obvious to anyone besides me.  I will kajigger with it for a while until I get the magic email that will allow me to get the compiler upgrade.  Thanks for your help, all of you, not just responders but readers also.  This is a great community.  Regards, Paul

Well, that was fast.  I kept commenting out larger and larger chunks of code, trying to survive a compile.  Finally, I was down to just this:

Device = 12F675  (yes, I commented out the line from the code configurator.)
Xtal = 4
All_Digital = True

and it still hangs.  It must really not like me anymore.  I tried to debug the loader error, but I got:  "Unhandled exception at 0x777DFB03 (ntdll.dll) in Loader.exe: 0xC0000005: Access violation writing location 0x20202034." but that of course means nothing to me.  Must be a corrupted file in the compiler, however, I can still compile other programs that use the 16F675 (it is my favorite 8 pin PIC).  Very bizarre.  I guess I will hang loose until my upgrade credentials arrive, and hope that fixes the issue. It may take a day or two, but I will report back success (or failure).  Thanks

Okay, now I'm dumbfounded (rather than just dumb).  I tried it the other way around, pasting the above 3 lines into a new program with a different name and it compiled properly (only 12 words used).  I then started adding back in code chunks, a piece at a time, and it kept compiling.  Finally, I was able to compile the entire program properly (like Trastikata's screen shot above), only with a different name (TestCompile instead of PulseProbeRGB).  It works perfectly now, but I don't know why this would make a difference?  Finally, I erased the old file PulseProbeRGB then renamed and resaved TestCompile to PulseProbeRGB, and now it compiles perfectly.

I better stop now, blood is coming out of my ears. 

That's Windows for you!

Bob

RGV250, you may be right.  I'd better roll back to DOS 3.3! 

The Loader does not do anything extraordinary. It just works in text and creates temporary files etc...

It scans the code listing passed to it in the command line, and includes any code from "Include" directives, and adds line number and file reference to each line's beginning. So the compiler knows were a line of code is, and what to reference for an error message etc...

It detects what device type is being used by the "Device" directive and then calls the preprosessor, which scans the file passed to it, processes it, and creates a temporary file that the Loader reads and passes to the compiler itself, and the compiler it calls is dependent on the "Device" directive it read from the code listing.

So if it is giving errors, it is windows, or a third party on windows, looking at the files created and panicing for some reason. Mainly because of "best guess" mechanisms in 'so called' virus checkers etc...

Interesting...  so it's not even the name of the file that was causing it to hang, but that particular stored file that was somehow corrupted during storage in the SSD.  Deleting and replacing it restored functionality.  Still, it prompted me to request/pay for an upgrade, so that's probably good (I deserved a Christmas present).  The idea about rolling back Windows probably wasn't bad either. 

The text files may have gained some characters not normally used by the BASIC compiler, i.e. ASCII characters less than 32 or over 127. I'm not sure how Positron handles those but it is my explanation for rare instances of very odd behaviour with certain files where nothing odd is visible in an editor, but things don't go right, and reverting to a previous version cures the problem.

John

Quote from: dr-zin on Dec 30, 2025, 12:13 PMit prompted me to request/pay for an upgrade, so that's probably good (I deserved a Christmas present).

Version 3.7.3.6 is very old.
If you're getting yourself an Positron compiler upgrade for Christmas, you'll be very happy with it.
Many new features have been added.
You'll especially appreciate the use of procedures, something version 3.x.x.x doesn't have.