Menu

PIC16F18857

jackjames
2020-09-14
2020-11-20
  • jackjames

    jackjames - 2020-09-14

    THIS IS NOT A DAT FILE ERROR - THIS WAS A COMPILER ISSUE. A COMPILER LATER THEN 30th Sept 2020 resolves


    I have changed the old file with the new with correct ram size.
    It give me this error:
    Aborting due to runtime error 6 (out of bounds array access) at line 14361 of D:\code\GCBASIC\trunk\gcbasic.bas::READCHIPDATA()

     

    Last edit: Anobium 2020-09-30
  • Anobium

    Anobium - 2020-09-14

    How odd.

    What version of the compiler?
    Can you attach the dat file and your source program. Please.

    Anobium

     
  • jackjames

    jackjames - 2020-09-14

    The version is 0.98.06 2019-06-12
    The source file is big with some include files.
    If you give me an email address I will send you a zip with all files.

     
  • Anobium

    Anobium - 2020-09-14

    Try the current Release Candidate first. See the files tab. install to a new directory. Test and report back.

     
  • jackjames

    jackjames - 2020-09-14

    OK

     
  • jackjames

    jackjames - 2020-09-14

    The new compiler is Ok. No errors.
    Now I try it in practice and see if the compiled works well.
    Thanks Anobium

     
    • Anobium

      Anobium - 2020-09-14

      OK. The RC code is stable and you cam use safely.

       
  • jackjames

    jackjames - 2020-09-15

    The program was compiled without errors.
    However, I found some errors in the string handling.
    I'll explain:
    In my program I display data on an LCD display with also graphic symbols.
    With the new compiler these characters were not displayed to me. I started a step-by-step verification by partializing various areas of the program and finally I discovered that the problem was due to the size of a string:
    Dim sString as string * 6
    It looked OK ...
    After many tests I spaced the 6 from the symbol * and the program, at least in that part, worked.
    I have encountered another problem in the transfer of strings that is not happening correctly.
    I have prepared a test program where the error occurs and a screenshot with the result obtained.
    In practice it is a question of making a string exit from the serial port that I pass to an output routine.
    Code:

    '       $formattagcb
            #Option Explicit
    '       -
    '       -
            #Chip 16F18857, 32
            #Config OSC = INT, MCLR_OFF
    '       -
    '       Configurazione dei pins per la seriale e il bus I2C
            #startup InitPPS, 85
            #Define PPSTOOLPART 16f18857
    
    '       - Setup Serial port
            #Define USART_BAUD_RATE 2400
    '       #Define USART_TX_BLOCKING
    '       #Define USART_DELAY 5 ms
    '       #Define USART_BLOCKING
    '       -
            #Define SERINPORT  PORTB.2
            #Define SEROUTPORT PORTB.5
    
            Dim Cnt As Byte
    '       -
            Cnt = 0
            Do ForEver
               Printst ("Count=", 0)
               Wait 100 ms
               Printst (STR (Cnt), 1)
               Wait 100 ms
               Cnt ++
            Loop
    '       -
    '       -
    '       ========================================================================
    '       Scrive una stringa sulla seriale
    '       ------------------------------------------------------------------------
    Sub Printst (in Stringa As String, Optional NumCrlf As Byte = 0)
            HSerPrint Stringa
            If NumCrLf Then
               Repeat NumCrLf
                  HSerPrintCrLf
               End Repeat
            End If
    End Sub
    '       -
    '       -
    Sub InitPPS
    '       Generated by PIC PPS Tool for Great Cow Basic
    '       PPS Tool version: 0.0.5.26
    '       PinManager data: v1.76
    '       Generated for 16f18857
    '       -
            UnLockPPS
    '          Module EUSART
               RB5PPS     = 0x0010    'TX > RB5
               RXPPS      = 0x000A    'RB2 > RX
    '          Module MSSP1
               SSP1DATPPS = 0x0009    'RB1 > SDA1
               RB1PPS     = 0x0015    'SDA1 > RB1 (bi-directional)
               RB4PPS     = 0x0014    'SCL1 > RB4
               SSP1CLKPPS = 0x000C    'RB4 > SCL1 (bi-directional)
            LockPPS
    End Sub
    
     
  • Anobium

    Anobium - 2020-09-15

    This is because the USART routines have been optimised.

    I have reproduced your issue and if you add the USART_TX_BLOCKING this should resolve your issue.

    ~~~
    #Define USART_BAUD_RATE 2400
    #Define USART_TX_BLOCKING
    #Define USART_DELAY 0
    ~~~

    and, you cannot use Software serial and Hardware serial unless you are turning PPS on and off as you use Software serial.

    Anobium

     

    Last edit: Anobium 2020-09-15
  • jackjames

    jackjames - 2020-09-20

    On this program that I'm writing I used the compiler 0.98.07.
    The same source code compiled with version 0.98.06 produced me a code of 20227 bytes and 2018 bytes of RAM.
    With the .07 version the code is 20102 bytes and the RAM used is 2017, therefore a good saving of program memory.
    However, I found a problem that I was unable to solve,
    now I'll explain:
    In my program (over 6000 lines of code) in the display I use graphic characters created with "LCDCreateChar". With the previous compiler you can see perfectly, with version .07 I see characters completely different from those generated and, always the same character for each of the graphic characters created, that is, for each different graphic character the same "strange" character is always displayed .
    If I use the "LCDCreateChar" instruction on a new test program, everything works fine.
    As I said the code is over 6000 program lines and to work and see the results on the display it must be connected to other hardware.
    The .06 version does not give any problems ...

     
    • Anobium

      Anobium - 2020-09-20

      Please upload ASM files from both compilers.

      As we have not changed the LCD CreateChar we need to look elsewhere.

       
  • jackjames

    jackjames - 2020-09-20

    OK.
    Source included.

     
  • Anobium

    Anobium - 2020-09-21

    This may be a memory defintion issue. Please upload both chip .dat file from both versions.

     
  • jackjames

    jackjames - 2020-09-21

    OK.
    Chip.dat included

     
  • Anobium

    Anobium - 2020-09-21

    Thank you. I have examined the [FreeRAM] section. I see no errors. There is a long list of RAM location (very different from V06 ) but they add up to 4096 - which is correct.

    Try using the V06 with the new compiler. I want to know if I even looking in the correction place. Rename to V07 (you will need it!).

     
    • Anobium

      Anobium - 2020-09-21

      And, looking at the old V06... this would not have worked as exepted. The chipRAM = 4096 but the actual RAM map is for a 2048 RAM device. I am not sure woud have happened when the RAM address went about 2048!

       
  • Anobium

    Anobium - 2020-09-21

    And, wading thru your asm...

    Looks ok here in the simulator... are these your chars?

    Do you have #option explicit set?

     

    Last edit: Anobium 2020-09-21
  • Anobium

    Anobium - 2020-09-21

    This does look seriius. The ASM had 38 inccorect or missing BANKSELs,

    Problably the DAT file but I do not know. I need the source GCB program.

     
  • jackjames

    jackjames - 2020-09-21

    OK. I'm away from home right now.
    It seems strange to me that the .06 compiler with its .dat file allows me to run the whole program without any problem.
    As soon as I return, I send you the source files.
    Send me an email address where I can send you the files.

     
    • Anobium

      Anobium - 2020-09-21

      OK. It is not strange howerver.

      06 - may have worked but the memory map was incorrect.
      07 - the memory map is correct but it has BANKSEL errors. Lots of them.

      So, we can revert all the 4096RAM chips (all of them) back to 2048RAM,or, we resolve properly.

      07 is currently a release candidate with 100s of fixes. And, there will be issues along the way. Sorry.

      Send me a Personal Message for my email address.

       
  • Anobium

    Anobium - 2020-09-27

    I have investigated, a lot, more.

    The root cause is the cause that BANK 32 of the RAM is being incorrectly handled. It is impact the following chips.

    PIC16F18857
    PIC16F18877
    PIC16F19197

    I have created a test program that uses every byte of RAM, and, whilst the compiler handles the assignment of the RAM correctly the generated ASM is incorrect.


    There is also a related issue where the memory map description for these chips prior to v0.98.07 is incorrect.


    We are working the solution.

     
    • SPostma

      SPostma - 2020-11-20

      Dear Evan,

      There now exist two different encodings forthe MOVLB instruction on Enhanced Mid-range devices; see https://www.microchip.com/forums/m1131489.aspx

      One for devices with 32 banks:
      "00 0000 001k kkkk" The 9-bit prefix 00 0000 001 was unassigned in the Baseline Mid-range devices.

      And one for Enhanced Mid-range devices with 64 banks:
      "00 0001 01kk kkkk" Which uses some of the unused encodings previously occupied by CLRW;
      CLRW must now be encoded as: "00 0001 0000 00xx"

      See the PIC16F18857 datasheet, which correctly shows "00 0001 01kk kkkk" (14 bits).

      this is little known; I hope this helps you fix this problem...

       
      • Anobium

        Anobium - 2020-11-20

        We resolved this a while ago. But, thank you.

         
  • Anobium

    Anobium - 2020-09-30

    @JackJames. My email are not getting to you.

    Please email me your project. I cannot test with no project but here is video of my analysis todate.

     

    Last edit: Anobium 2020-09-30

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.