Today 12:34
Forum: Proton Plus Compiler v3
Starter: joesaliba
Views: 0
Replies: 6
Yesterday 23:47
Forum: Proton Plus Compiler v3
Starter: johngb
Views: 0
Replies: 11
Yesterday 16:26
Forum: Proton Plus Compiler v3
Starter: Dave-S
Views: 0
Replies: 9
Closed Thread
Results 1 to 6 of 6
  1. #1
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,328
    Thumbs Up
    Received: 49
    Given: 123
    Total Downloaded
    2.37 GB

    0 Not allowed!

    Default Possible problem if TBLPTR registers are changed

    Don't know how specific this is or if this is finger trouble at my end, correct behaviour or a feature but if when using @tblrd * if I don't save and restore the TABPTR registers, string handling becomes erratic. In my case I'm using the standard code to get the device ID. Maybe the runtime assumes values in the top reg? BTW I don't have ints running.

    Code:
        D_Data1 = TBLPTRU                           ' save pointer
        D_Data2 = TBLPTRH                           ' 
        D_Data3 = TBLPTRL   
    
        TBLPTRU = DevIDU                            ' upper
        TBLPTRH = DevIDH                            ' high
        TBLPTRL = DevIDL                            ' low
        @tblrd *
        D_Data = TABLAT                             ' DEVID1
        GoSub D_SendByteAndUpCRC                    '
    
        TBLPTRL = DevIDL + 1                        ' low
        @tblrd *
        D_Data = TABLAT                             ' DEVID2
        GoSub D_SendByteAndUpCRC                    '
    
        TBLPTRU = D_Data1                           ' restore pointer
        TBLPTRH = D_Data2                           ' 
        TBLPTRL = D_Data3
    George

  2. #2
    Senior Member AlbertoFS's Avatar
    Join Date
    Apr 2005
    Posts
    583
    Thumbs Up
    Received: 76
    Given: 2
    Total Downloaded
    1.93 GB

    1 Not allowed!

    Default Re: Possible problem if TBLPTR registers are changed

    Hi George,
    What is the PIC you are using? According to the PIC the way of reading the ID can change. TBLPTRU, TBLPTRH & TBLPTRL are the bytes that define the address of the first byte to read/write in the ROM. Then you must to use "Tblrd*+" (all letters together) to read each byte of the information. "+" means incrementing TBLPTRU, TBLPTRH & TBLPTRL after reading/writing (see the PIC datasheet). In your code, you increment TBLPTRL, but not the other bytes address, which can cause a jump in an unknown memory location in some cases.
    I had the same problem in the past because I did not know how to handle the memory. You could see all kinds of examples of how to read and write in the ROM in my different Bootloaders in the wiki.

    After reading the ROM, TBLPTRU must be = 0, because it could affect the reading of the strings written in the ROM using HRSOut for example.
    The PIC ID is part of the PIC configuration, so you should use "EECON1 = Bin11000000 before to read and "EECON1 = 0" after the routine. I put it always, because it can cause erratic functioning.
    Code:
         Dim DataWord A Word
         Dim PICPartNumber As Byte
         Dim PICRevision As Byte
    
         Symbol ID_ADDRESS = $3FFFFE     ' Write the ID address. Location of (DEVID1) in memory map, see the datasheet
    
    
    ' Read the PIC ID from Config fuse.
        EECON1 = Bin11000000              ' Access Configuration registers    
        TBLPTRL = ID_ADDRESS & $0000FF
        TBLPTRH = (ID_ADDRESS >> 8) & 255
        TBLPTRU = (ID_ADDRESS >> 16) & 255
        Tblrd*+                         ' perform table read with post-increment
        DataWord.LowByte = TABLAT
        Tblrd*+                         ' perform table read with post-increment
        DataWord.HighByte = TABLAT        
        TBLPTRU = 0                     ' Cleared for security
        EECON1 = 0                      ' Disable Access the Configuration registers
    
        ' Calculate the PIC Part Number & revision
        PICPartNumber = DataWord >> 5
        PICRevision = DataWord.LowByte & 31
    Regards
    Alberto
    Last edited by AlbertoFS; 13th September 2017 at 19:33.
    [U]73's de Alberto ea3agv[/U]

  3. #3
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,328
    Thumbs Up
    Received: 49
    Given: 123
    Total Downloaded
    2.37 GB

    0 Not allowed!

    Default Re: Possible problem if TBLPTR registers are changed

    To late to edir the above.

    Same effect seen with cPtr8 which also uses TBLPTR regs. I note that it only sets L and H. (is it TBLPTRLH or TBLPTRH?)
    George

  4. #4
    Senior Member AlbertoFS's Avatar
    Join Date
    Apr 2005
    Posts
    583
    Thumbs Up
    Received: 76
    Given: 2
    Total Downloaded
    1.93 GB

    1 Not allowed!

    Default Re: Possible problem if TBLPTR registers are changed

    In fact, you are right. cPtr8 uses TBLPTRH & TBLPTRL for PIC with memory <= 64Kb. It is normal. But it does not use TBLPTRU for memory > 64Kb ???, for example the PIC18F27K40. I will study it in detail tomorrow.
    Regards
    Alberto
    [U]73's de Alberto ea3agv[/U]

  5. #5
    Developer Les's Avatar
    Join Date
    Feb 2002
    Posts
    3,231
    Thumbs Up
    Received: 229
    Given: 83
    Total Downloaded
    1.50 GB

    1 Not allowed!

    Default Re: Possible problem if TBLPTR registers are changed

    I can find nothing wrong with the Tblrd* mnemonic in the BASIC code, and also remember, there is no need to add the @. Simple mnemonics are recognised by the BASIC as well:

    Tblrd*

    ALberto is correct, TBLPTRL, TBLPTRH and TBLPTRU are a 24 bit SFR, so the need to be incremented. Or use only TBLPTRL and TBLPTRH for devices with less than 64K of flash memory.

    The TBLPTRU SFR is used when the Declare Access_Upper_64k = 1 is added to the program. This is because using the TBLPTRU on devices with less than 64K of flash is a waste of time and code memory, so by default, it is not, usually, accessed.

    A simple program that illustrates how to access flash of all sizes is:

    Code:
        Device = 18F25K20
        Declare Xtal= 64      
        Declare Access_Upper_64k = 1    ' Use the TBLPTRU SFR as well for flash access above 64K
        
        Dim MyByte As Byte
        Dim MyAddress As Dword = $FFFF
        
        Do
            MyByte = cPtr8(MyAddress++)
        Loop
    I thought I'd added the Declare to the manual a few years ago, but it's not in there. I'll add it to the next manual update.
    Last edited by Les; 14th September 2017 at 08:54.
    For more example programs for Proton and Proton24 or updates, please visit: Proton WIKI or Proton Files

  6. #6
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,328
    Thumbs Up
    Received: 49
    Given: 123
    Total Downloaded
    2.37 GB

    0 Not allowed!

    Default Re: Possible problem if TBLPTR registers are changed

    Sorry Les, I wasn't saying there was anything wrong with the Tblrd* mnemonic or the compiler, the upshot was that if you change the TBLPTRU register you should set it to 0 after use (because the compiler quite reasonably assumes it is 0)
    George

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Similar Threads

  1. Replies: 7
    Last Post: 22nd August 2017, 11:04
  2. Can symbols be changed on the fly?
    By spyder0069 in forum Proton Plus Compiler v3
    Replies: 4
    Last Post: 24th September 2009, 08:53
  3. how do i get my info changed?
    By Dphil7532 in forum Proton Plus Compiler v3
    Replies: 1
    Last Post: 10th September 2008, 01:58
  4. Changed after compilation option
    By Jongerius in forum Wish List / Product Feedback
    Replies: 2
    Last Post: 6th July 2005, 18:17

Members who have read this thread since 27th October 2017, 20:19 : 0

Actions :  (Set Date)  (Clear Date)

You do not have permission to view the list of names.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts