DEFINE RESET_ORG and DEC modifier issue

[Marcick]

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 ?





' 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

[richard]

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

[Marcick]

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/picbasic-pro-compiler-3-0-and-later/pbp3-picbasic-pro-3-0/8201-define-reset_org-and-dec-modifier-issue

[richard]

. 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.




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


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

[Marcick]

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

[richard]

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.





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

[richard]

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

[Marcick]

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 (http://support.melabs.com/forum/picbasic-pro-compiler-3-0-and-later/bug-report-pbp3/8205-define-reset_org-and-dec-modifier-issue-above-64k).
Thanks

[richard]

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

[Marcick]

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.

[richard]

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

[HenrikOlsson]

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.

[Marcick]

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 .....

[richard]

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.

[Marcick]

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

[Marcick]

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.
"

[richard]

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

[Marcick]

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

[richard]

arraywrite to a buffer then hserout str buffer

[Marcick]

I'll do some test, thank you :)

[Marcick]

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

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

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 ?

[richard]

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

[Marcick]

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.

[pedja089]

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

[richard]

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


a message database of null terminated strings


@ 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


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

[Marcick]

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


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