Proton version numbers and EEPROM scrambling

[PicNoob]

Hey guys,

Long time proton user here. I have a program for the 18F2580 I'm migrating over to the newest proton version. I have both versions installed so I can work back and forth opening just one at a time.

First question: The version numbers in proton "about" make no sense to me. This is the "older" version, I think circa 2015? It uses the USB key.

IDE: 2.0.3.3
Loader 3.5.0.6
Proton Compiler 3.5.0.6

While the latest version Les sent over shows under "about":

IDE 2.0.3.3
Loader 1.0.3.2
Proton Compiler 3.5.0.6

The only difference I see is the "loader" and the number is smaller in the new version. How do I tell what version I'm actually using?

Second thing. I've updated a bin so it works in both versions, just having to switch "proton_start_address" in old version to "compiler_start_address" in new version. It mostly works fine but playing with the optimizer levels in the new version it appears to default to Declare Optimiser_Level 3 even if I comment out the line. I need to specify Declare Optimiser_Level 0 if I don't want to optimize. Is that normal for the new version?   
 
Finally the big issue I'm having is the new version scrambles the EEPROM while the old version does not. It's difficult to replicate on the test bench so I'm sure its something related to EEPROM writes and interrupts or power levels but so far can't find it. 

These old chips also only have 256k EEPROM and I use most of it so migrating to a 3x read/write solution isn't practical for this application. I'll be doing that on the new chip applications for sure though.
 
Is there anything different about EWRITE from old version to new? I've noticed I had instances of not disabling interrupts before an EWRITE but the old compiled version never had an issue with it. And adding a GIE = 0 above every EWRITE has so far not resolved the issue on the new version.

I'll keep trying to figure out how to replicate it on the test bench but figured some old timers may know of some proton change or something I'm not aware of.

[trastikata]

Hi,

I have found that breaking larger than a byte variables Ewrites to bytes and adding a delay of 7ms solves the issue.

For example Ewrite Address, [MyWord.byte0] : delayms 7 : Ewrite Address+1, [MyWord.byte1] : delayms 7

About the version, check the top of the assembler code.

[RGV250]

Hi John,
Regards the version, if you have the Positron one the IDE will show an old version, what you need to do is compile and then look at the asm.
I think Fineline and Positron studio show the right version.

;   /\\\\\\\\\
;  /\\\///////\\\
;  \/\\\     \/\\\                                                 /\\\          /\\\
;   \/\\\\\\\\\\\/        /\\\\\     /\\\\\\\\\\     /\\\\\\\\   /\\\\\\\\\\\  /\\\\\\\\\\\  /\\\\\\\\\
;    \/\\\//////\\\      /\\\///\\\  \/\\\//////    /\\\/////\\\ \////\\\////  \////\\\////  \////////\\\
;     \/\\\    \//\\\    /\\\  \//\\\ \/\\\\\\\\\\  /\\\\\\\\\\\     \/\\\         \/\\\        /\\\\\\\\\\
;      \/\\\     \//\\\  \//\\\  /\\\  \////////\\\ \//\\///////      \/\\\ /\\     \/\\\ /\\   /\\\/////\\\
;       \/\\\      \//\\\  \///\\\\\/    /\\\\\\\\\\  \//\\\\\\\\\\    \//\\\\\      \//\\\\\   \//\\\\\\\\/\\
;        \///        \///     \/////     \//////////    \//////////      \/////        \/////     \////////\//
;                                  Let's find out together what makes a PIC Tick!
;
; Code Produced by the Positron8 Compiler. Version 4.0.4.2
; Created and Written by Les Johnson.
; Compiler version for Your name here.
;----------------------------------------------------------

Bob

[PicNoob]

Hi,

I have found that breaking larger than a byte variables Ewrites to bytes and adding a delay of 7ms solves the issue.

For example Ewrite Address, [MyWord.byte0] : delayms 7 : Ewrite Address+1, [MyWord.byte1] : delayms 7

About the version, check the top of the assembler code.

Interesting, I will evaluate this. I'm operating in a real time environment and I can't keep interrupts down that long. But I can probably come up with a way to run them like this in the background.

Good tips on the ASM code! The new version is 4.0.4.8 while the old version is 3.5.0.6.

So I'm not very knowledgeable about assembler level code. Looking at a specific EWRITE command in the same program compiled in v3.5:

F1_001353 EQU $ ; IN [MAC_8.BAS] SAFETY_LAST = 0
        MOVLB 1
        CLRF SAFETY_LAST
F1_001354 EQU $ ; IN [MAC_8.BAS] EWRITE 62,[SAFETY_LAST]
        MOVLW 62
        MOVWF EEADR,0
        MOVF SAFETY_LAST,W
        CALL EE@WR
        MOVLB 0
        GOTO BC@LL80

Then same write code in v4.0

F1_001353 equ $ ; in [MAC_8.BAS] safety_last = 0
    movlb 0x01
    clrf safety_last,1
F1_001354 equ $ ; in [MAC_8.BAS] Ewrite 62,[safety_last]
    movlw 62
    movwf EEADR,0
    movf safety_last,W,1
    call __eewrite_
    movlb 0x00
    goto _lbl__82

Is there any significant difference? I see an extra parameter on the movf. What does ",1" do?

[diebobo]

Also show the ASM for function  call __eewrite_...  Thats where u might find more changes.

[Dompie]

In the datasheet of the PIC you are using there is a chapter INSTRUCTION SET and in this chapter you will find all the assembler information. Also the 1 you are looking for (RAM access bit).

Code Select Expand

TABLE 25-1: OPCODE FIELD DESCRIPTIONS
a RAM access bit
a = 0: RAM location in Access RAM (BSR register is ignored)
a = 1: RAM bank is specified by BSR register
Johan

[trastikata]

Interesting, I will evaluate this. I'm operating in a real time environment and I can't keep interrupts down that long. But I can probably come up with a way to run them like this in the background.

You don't have to stop interrupts while waiting, just wait for this time before sending the next byte to be written in EEPROM. Thus something like this:

Code Select Expand

INTCON.7 = 0
EWrite 2,[wTemp.Byte0]
INTCON.7 = 1
DelayMS 7
INTCON.7 = 0
EWrite 3,[wTemp.Byte1]
INTCON.7 = 1
DelayMS 7


[PicNoob]

Also show the ASM for function  call __eewrite_...  Thats where u might find more changes.

Good idea! The only obvious thing I spotted was an extra "bsf EECON1,PP_EEPGD" at the end of the new compiler.

EE@WR
EE@WR@W
        MOVWF 4008
        CLRF 4006
        BSF 4006,PP_WREN
        MOVLW 85
        MOVWF 4007
        MOVLW 170
        MOVWF 4007
        BSF 4006,PP_WR
        BTFSC 4006,PP_WR
        BRA $ - 2
        BCF 4006,PP_WREN
        INCF 4009,F
        RETURN

__eewrite_
__eewrite_w_
    movwf EEDATA
    clrf EECON1
    bsf EECON1,PP_WREN
    movlw 85
    movwf EECON2
    movlw 170
    movwf EECON2
    bsf EECON1,PP_WR
    btfsc EECON1,PP_WR
    bra $ - 2
    bcf EECON1,PP_WREN
    incf EEADR,F
    bsf EECON1,PP_EEPGD
    return

[PicNoob]

In the datasheet of the PIC you are using there is a chapter INSTRUCTION SET and in this chapter you will find all the assembler information. Also the 1 you are looking for (RAM access bit).

Code Select Expand

TABLE 25-1: OPCODE FIELD DESCRIPTIONS
a RAM access bit
a = 0: RAM location in Access RAM (BSR register is ignored)
a = 1: RAM bank is specified by BSR register
Johan

Thanks! The datasheet says 1 is the default so likely the two versions are equivalent. I'll keep looking for possible causes.

If 'a' is '0', the Access Bank is selected.
If 'a' is '1', the BSR is used to select the
GPR bank (default).

[PicNoob]

I disabled interrupts all together on the v4 proton compiled version and its still (sometimes) blowing out all of EEPROM during startups. And the same program compiled in v3.5 doesn't. So bizarre.

I'm at least able to recreate the issue easily enough here. Been randomly trying things like a higher BOR, commenting out blocks of code, optimizer on/off, etc. So far not found anything. I could just not migrate this specific program to the new compiler but now I'm wondering if I'm leaving a time bomb in other programs I am migrating that seem to work fine.

[trastikata]

By allowing enough time between EEPROM writes, I never had an issue.

It could be something device specific or code specific, even design noise etc.

[PicNoob]

By allowing enough time between EEPROM writes, I never had an issue.

It could be something device specific or code specific, even design noise etc.

There are lots of possible causes but I have widely narrowed it down some.

Using the same hardware I can recreate the issue on the program compiled in v4 but not in the same program compiled in v3.5. Boot loader (first 2k) is compiled in v4 and has no influence on the issue.

The EEPROM getting scrambled is the largest symptom but not the only one. I've also got a couple variables that appear to be overwritten and recover when interrupts are running on the v4 version. The variables are assigned from CANbus so that is something else I need to chase down. But again once I revert back to 3.5 its all fine.

The EEPROM scramble I'm confident is happening around boot up, despite various BOR settings or no BOR at all. It happens when there isn't even any EEPROM writing going on, only reading. I just don't see what v4 could be doing there that v3.5 doesn't. Any hardware issue or noise I'd expect to influence both equally. I'm hoping there is a "declare fuck_with_my_project = on" setting in v4 that is on by default.

[John Lawton]

Any hardware issue or noise I'd expect to influence both equally

This is odd. Check that you have specifically defined the startup value of all relevant variables as this area might be subtly different between compiler versions.

What is the oscillator setup and is there a startup delay in the code?

Are you sure about your hardware design, could there be Vcc line noise or poor regulation possibly causing the EEPROM issues?

Good luck.

John

[PicNoob]

Any hardware issue or noise I'd expect to influence both equally

This is odd. Check that you have specifically defined the startup value of all relevant variables as this area might be subtly different between compiler versions.

What is the oscillator setup and is there a startup delay in the code?

Are you sure about your hardware design, could there be Vcc line noise or poor regulation possibly causing the EEPROM issues?

Good luck.

John

This specific hardware has been in use for around 10 years and I believe it's solid, but of course power related issues were my first suspect. After I exhausted those I finally started testing the exact same hardware in the exact same environment new vs old compiler to determine that it was only the v4 compiled code that scrambled EEPROM.

This specific application has an external oscillator at 40mhz, with around a 100ms delay in the boot loader before firing up. It's been fine all these years but on my to-try list is even longer startup delays just to see if I can find any correlation.

That is a good idea on the startup declares, etc. I feel like it has to be something simple I'm missing!

Another oddity is I can't recreate it on the test bench directly. But I can easily in application (automotive). So sorting out the difference between my test bench and the actual application is also on my to-do list. That was what lead me first to think this is a power/startup issue (and the new compiler was just a coincidence) but I've tried all sorts of low voltages and noise introduction on the test bench to no avail in recreating. The one thing I'm unable to recreate to the same level is the high speed CANbus which got me thinking it was interrupt related but when I shut those down all together in application, same scramble. So frustrating!