DEFINE RESET_ORG and DEC modifier issue

Sorry I open again a thread but the other one was not exact in the question.

In the code below I use a simple DEC modifier to output a string and it works as expected.
But If I use the "DEFINE RESET_ORG 1EC00h" it doesn't work and the devices seems to reset continuously.
How is it possible ?

Code:

---


' DEFINE RESET_ORG 1EC00h
' device=PIC18F67K22


    #CONFIG
    CONFIG  RETEN = ON          ; Enabled
    CONFIG  INTOSCSEL = LOW      ; LF-INTOSC in High-power mode during Sleep
    CONFIG  SOSCSEL = DIG        ;
    CONFIG  XINST = OFF          ; Disabled
    CONFIG FOSC = INTIO2        ; Internal RC oscillator
    CONFIG  PLLCFG = OFF          ; Enabled
    CONFIG  FCMEN = OFF          ; Disabled
    CONFIG  IESO = OFF            ; Disabled
    CONFIG  PWRTEN = OFF          ; Disabled
    CONFIG  BOREN = SBORDIS      ; Enabled in hardware, SBOREN disabled
    CONFIG  BORV = 2              ; 2.0V
    CONFIG  BORPWR = ZPBORMV      ; ZPBORMV instead of BORMV is selected
    CONFIG  WDTEN = OFF
    CONFIG  WDTPS = 256          ; 1:256
    CONFIG  RTCOSC = SOSCREF      ; RTCC uses SOSC
    CONFIG  CCP2MX = PORTC        ; RC1
    CONFIG  MSSPMSK = MSK7        ; 7 Bit address masking mode
    CONFIG  MCLRE = ON            ; MCLR Enabled, RG5 Disabled
    CONFIG  STVREN = ON          ; Enabled
    CONFIG  BBSIZ = BB2K          ; 2K word Boot Block size
    CONFIG  DEBUG = OFF          ; Disabled
      CONFIG  CP0 = OFF            ; Block 0 (000800, 001000 or 002000-003FFFh) not code-protected
    CONFIG  CP1 = OFF            ; Block 1 (004000-007FFFh) code-protected
    CONFIG  CP2 = OFF            ; Block 2 (008000-00BFFFh) code-protected
    CONFIG  CP3 = OFF            ; Block 3 (00C000-00FFFFh) code-protected
    CONFIG  CP4 = OFF            ; Block 4 (010000-013FFFh) code-protected
    CONFIG  CP5 = OFF            ; Block 5 (014000-017FFFh) code-protected
    CONFIG  CP6 = OFF            ; Block 6 (01BFFF-018000h) code-protected
    CONFIG  CP7 = OFF            ; Block 7 (01C000-01FFFFh) code-protected
    CONFIG  CPB = ON            ; Boot Block (000000-0007FFh) code-protected
    CONFIG  CPD = OFF            ; Data EEPROM code-protected
    CONFIG  WRT0 = OFF            ; Block 0 (000800, 001000 or 002000-003FFFh) not write-protected
    CONFIG  WRT1 = OFF            ; Block 1 (004000-007FFFh) not write-protected
    CONFIG  WRT2 = OFF            ; Block 2 (008000-00BFFFh) not write-protected
    CONFIG  WRT3 = OFF            ; Block 3 (00C000-00FFFFh) not write-protected
    CONFIG  WRT4 = OFF            ; Block 4 (010000-013FFFh) not write-protected
    CONFIG  WRT5 = OFF            ; Block 5 (014000-017FFFh) not write-protected
    CONFIG  WRT6 = OFF            ; Block 6 (01BFFF-018000h) not write-protected
    CONFIG  WRT7 = OFF            ; Block 7 (01C000-01FFFFh) not write-protected
    CONFIG  WRTC = OFF            ; Configuration registers (300000-3000FFh) not write-protected
    CONFIG  WRTB = OFF            ; Boot Block (000000-007FFF, 000FFF or 001FFFh) not write-protected
    CONFIG  WRTD = OFF            ; Data EEPROM not write-protected
    CONFIG  EBRT0 = OFF          ; Block 0 (000800, 001000 or 002000-003FFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT1 = OFF          ; Block 1 (004000-007FFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT2 = OFF          ; Block 2 (008000-00BFFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT3 = OFF          ; Block 3 (00C000-00FFFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT4 = OFF          ; Block 4 (010000-013FFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT5 = OFF          ; Block 5 (014000-017FFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT6 = OFF          ; Block 6 (018000-01BFFFh) not protected from table reads executed in other blocks
    CONFIG  EBRT7 = OFF          ; Block 7 (01C000-01FFFFh) not protected from table reads executed in other blocks
    CONFIG  EBRTB = OFF          ; Boot Block (000000-007FFF, 000FFF or 001FFFh) not protected from table reads executed in other blocks
    #ENDCONFIG


    DEFINE            OSC            8
    DEFINE            HSER2_RCSTA        90H
    DEFINE          HSER2_TXSTA      24H
    DEFINE            HSER2_BAUD        19200
    DEFINE            HSER2_CLROERR    1


    CLEAR
    OSCCON        =
100000            ; Primary oscillator, internal 8MHz
    OSCCON2.0    =1
    OSCTUNE.7    =1
    Adr            VAR    WORD


loop1:
    FOR Adr=1000 TO 1005
        HSEROUT2 ["test1: ",13,10]                ' -->>>> this works always
        HSEROUT2 ["test2: ", DEC4 Adr,13,10]    ' -->>>> this works only if you comment the first line "DEFINE RESET_ORG 1EC00h"
    NEXT Adr
    PAUSE 1000
    CLEARWDT
    goto loop1

---

the obvious thing is that the bootloader is not right.
is the pbp re-entry point from bootloader correct ?
is the bootloader really capable of 128k operation ? eg are all the two word commands goto ,lfsr ... correctly configured
have the pbp shared lib routines been corrupted or inappropriately shifted ?
have you compared the lst files of working and no working code ?

or are you trying to make a bootloader ?
if so then have you enough room between 1ec00h and the end of memory to fit the
shared pbp routines library ? long version may be a fair bit bigger

uhhmmm.... where do you see I'm using a bootloader?
Well, I was really working on a bootloader but when I started to see this issue I wrote this simple code (not involving bootloader) to make this post.
I'm talking here also http://support.melabs.com/forum/picb...modifier-issue

Quote:

---

. where do you see I'm using a bootloader?

---

my bad, i was thinking back to bootloader issues i had with a 87j11 and 128k relocations going bad
with similar results.

a quick look at a lst file of your code shows a fair bit of this going on for the "DEC" section of your code
the upper portion of the hserout2j label address is ignored.

Code:

---

                          M    endif01EE4E 6A1C              M        clrf    (R2)  + 2
01EE50 6A1D              M        clrf    (R2)  + 3
                      00270        HSEROUT2DEC?   
                          M        MOVE?CW HSEROUT2J, R8    /// hserout2j  is a  more than a word long when >64k
                          M    ifdef USE_LINKER
                          M        CHK?RP  R8
                          M        movlw  low (HSEROUT2J)
                          M        movwf  R8
                          M        movlw  high (HSEROUT2J)
                          M        movwf  (R8)  + 1

---

hserout2j being a label

Code:

---

HSEROUT2                          0001EC06HSEROUT2?C                       
HSEROUT2COUNT?C                 
HSEROUT2DEC?                     
HSEROUT2J                        0001EC04
HSEROUT2J_USED                    00000001
HSEROUT2NUM?W                   
HSEROUT2_USED                    00000001
HSER_BAUD                        00000960
HSER_BITS                        00000008

---

hi,
It's a very long time I don't eat assembly...
Are you saying it's a PBP bug?

i'm not really sure what exactly the code is doing but the highlighted sections are doing something with the label but ignoring the upper byte of its address. below 64k its not an issue i would not say its bug , more like its not designed to be relocated beyond the 64k boundary.
anyways its the only thing i see in the code thats likely to be an issue.

Code:

---

01EE52 0E04              M        movlw  low (low (HSEROUT2J)) MPASM 5.61                          MCKD.ASM  1-30-2021  23:44:34        PAGE 32




LOC  OBJECT CODE    LINE SOURCE TEXT
  VALUE


01EE54 6E0A              M        movwf  R8
                          M      endif
                          M    endif
                          M        MOVE?CB high (HSEROUT2J), (R8) + 1
                          M        CHK?RP  (R8) + 1
                          M    if ((((R8) + 1) & 8000h) != PREV_ALT)
                          M      if (((R8) + 1) & 8000h)
                          M        bsf    WDTCON, ADSHR
                          M      else
                          M        bcf    WDTCON, ADSHR
                          M      endif
                          M PREV_ALT = ((R8) + 1) & 8000h
                          M    endif
                          M    if (((((R8) + 1) & 0fffh) > BANKA_END) & ((((R8) + 1) & 0fffh) < (0f01h + BANKA_END)))
                          M      if ((((R8) + 1) & 0f00h) != (PREV_BANK << 8))
                          M        movlb  high ((R8) + 1)
                          M PREV_BANK = high ((R8) + 1)
                          M      endif
                          M    endif
                          M    if (low (high (HSEROUT2J)) == 0)
                          M        clrf    (R8) + 1
                          M    else
                          M      if (low (high (HSEROUT2J)) == 255)
                          M        setf    (R8) + 1
                          M      else
01EE56 0EEC              M        movlw  low (high (HSEROUT2J))
01EE58 6E0B              M        movwf  (R8) + 1

---

maybe crashing here

01EDA8 6EE9 08880 JUMPMAN movwf FSR0L
01EDAA 6AFB 08881 clrf PCLATU
01EDAC 500B 08882 movf R8 + 1, W
01EDAE 6EFA 08883 movwf PCLATH
01EDB0 500A 08884 movf R8, W
01EDB2 6EF9 08885 movwf PCL

Looks like it is definitely a bug (I have bought one week ago the 3.1 update to be sure).
I'm writing in the bug report section of Melabs to see what they say. Here.
Thanks

you should verify the 3.1 version does the same thing , i used 3.0.10
i expect it will , the space shuttle was still a thing the last time the pbp core routines were enhanced

I was using 3.0 and bought 3.1 update to see if it was solved, but not.......
I think I will start to work on my subroutine to avoid use of string modifiers, though they are very powerful, it's a pity.

be wary any pbp command that uses jumpman the same way will probably fail , there may be other avenues of failure possible too

Yeah, until you here from Charles I'd be very careful with pushing the library routines beyond the 64k barrier.

I did compile the code and I did look at the .lst but I didn't see/understood the issue, nice work Richard! I know you've mostly moved on but please don't leave ;-)

/Henrik.

Charles says "I'll presume it's a bug and try to figure it out."
Let's wait.
I wonder if we could have same problem also without DEFINE RESET_ORG, just with code larger than 64k .....

i have never written a program that big with pbp , in fact if my code {excluding data fonts etc} got bigger than 16k would seriously think that a
8 bit pic with pbp is the wrong platform.

If you don't care too much to optimize, it's not difficult to arrive above 64k. For example I use a lot of Hserout messages just for debug of what the program is doing.
Really, a PIC18 is much more powerful than what I need

From Charles: "I'm afraid this is a limitation of PBP that probably won't be changed. The library routines (assembly language for high-level commands like HSEROUT) were written with the assumption that they would be in memory below 64K. They are the first thing placed after the RESET_ORG address. When I tested a variant of your code, the maximum address that could be safely defined was 0FFE4h. That limit will move down every time you use a new high level command which triggers a library inclusion.
"

Quote:

---

it's not difficult to arrive above 64k. For example I use a lot of Hserout messages just for debug of what the program is doing.

---

do you realise that hserout messages of a constant str type are the least efficient way to store and retrieve text ?
ditto for arraywrite

uhm ... how do you send a message to the serial port with ArrayWrite ?

arraywrite to a buffer then hserout str buffer

I'll do some test, thank you :)

Quote:

---

Originally Posted by richard

arraywrite to a buffer then hserout str buffer

---

These are my result:

1) simple program with some code and 1 line as below is 7099 bytes

Code:

---

        Hserout2["nel mezzo del cammin di nostra vita",13,10]

---

2) same program with 11 line like that is 9319 bytes, so each Hserout2 eat 222 bytes

3) simple program with some code plus this as below is 7157 bytes

Code:

---

        buf        VAR BYTE[200]
        arraywrite buf,["nel mezzo del cammin di nostra vita",13,10]
        gosub send

send:
        Hserout2[str buf\200]
        return

---

4) same program above but with 11 "arraywrite + send" is 9497 bytes, so each Hserout eat 234 bytes

Looks like it's not as you say. I did this test with PBP Long option enabled, maybe without the results are different ?

i think you misunderstand neither method is efficient
two hunted bytes to store a message 32 or so bytes long , not good

Quote:

---

Originally Posted by richard

i think you misunderstand neither method is efficient
two hunted bytes to store a message 32 or so bytes long , not good

---

I agree ... please explain how would you do. Of course debug strings are different and mixed also (fixed test, formatted variables, etc). Not possible to have them flashed in code memory.

Look at this
http://www.picbasic.co.uk/forum/showthread.php?t=137

Store raw data in FLASH. Terminate your string with 0.
Use readcode to read data, send one byte at time, and that is it.
So you can store 300 bytes in 300 bytes. Readcode take little space.
EDIT:
Another way is to store strings to EEPROM. So no code space is used.
http://www.picbasic.co.uk/forum/showthread.php?t=573

Quote:

---

please explain how would you do. Of course debug strings are different and mixed

---

a message database of null terminated strings

Code:

---

@ ORG 4000h
messages:
@ dw 0x08  ;message 0 offset 
@ dw 0x12  ;message 1 offset
@ dw 0x22  ;message 2 offset
@ dw 0x2e  ;message 3 offset
@ DB        "a message",0                                       
@ DB        "another message",0
@ DB        "and another",0                               
@ DB        "last one",0

---

to find a message[x] read from messages + 2*x this is the offset from messages label
message[x] start address = messages + offset

you can then copy message to a buffer and hserout it the usual way or create your own routine to
stream the message directly from flash

edited lst file

Code:

---

004000        00839  ORG 4000h
004000 0008          00847  dw 0x08
004002 0012          00855  dw 0x12
004004 0022          00863  dw 0x22
004006 0032          00871  dw 0x2E
                 
004008 2061 656D 7373 00879  DB    "a message",0                                           
    6761 0065
                     
004012 6E61 746F 6568 00887  DB    "another message",0
    2072 656D 7373
    6761 0065
                     
004022 6E61 2064 6E61 00895  DB    "and another",0                       
    746F 6568 0072
                   
00402E 616C 7473 6F20 00903  DB    "last one",0   
    656E 0000

---

Clear, thanks both. I've used something like that in the past when I needed a bunch of kbytes more to fit a program in memory.
But as I told debug strings are mostly mixed test+variables and become very difficult to manage this stuff, for example

Code:

---

Hserout2["logging ",DEC ByteCount," chars at @",HEX4 BaseAddress,"-Type ",HEX2 DataType,"-Data ",str inbuff\ByteCount*2,"-",HEX2 DataCrc,"                        "]

---

But some messages are all plain text, so I will consider to mix the two method :smile:

cheers