Wrong table reading in EEPROM

[Gigi]

I have three tables in eeprom, written correctly but only the first is read!
I attach code
Where am I going wrong?

[Anobium]

Sorry, I do not know what this issue is.

The table definition ( three of them ) are correctly written to the ASM as EEPROM. As shown below:

; Data Lookup Tables (data memory)
    ORG 0x2100
TableCODE0  equ 0
    de  4, 51, 51, 52, 128
TableCODE1  equ 5
    de  4, 51, 51, 53, 0
TableCODE2  equ 10
    de  4, 30, 31, 32, 33

Then, you read the tables and write them to location 0x30, 0x40,0x50. This can be seen in the picture below from the emulator.

So, you end up with the tables existing at 0x00 thru to 0x0E in EEPROM. And, the specific tables at the addresses 0x30, 0x40,0x50.

So, what is wrong? I would add some serial debug to this to figure this out.

[Gigi]

Thanks for the quick response
In my simulator it looks like this, why ???

[Gigi]

I enclose the control ASM

[Anobium]

The reason for the difference.. I am using PIC-AS to generate the HEX. I do this to test the solution.

So, your options as there is a BUG in GCASM. GCASM is the internal part of the toolchain that generates the HEX. Option 1. Use PIC-AS 2. Use MPASM. Using either of these will generate a valid hex.

All you need to do is install. From here https://sourceforge.net/projects/gcbasic/files/Support%20Files/MicrochipCompilers/ and then change to that tool in the Preferences Editor. Then, all should be good. Using these additional tools adds 1 second to the process but it will generate a good HEX for you.

---

Note: This is the first time I have ever seen an error in GCASM generating a HEX. That is since 2013.

[Gigi]

OK
I already have MPASM installed, how can I configure GCSTUDIO to use MPASM ?
Thank you

[Anobium]

In the Preferences Editor. Just select MPASM in the second tab.

[Gigi]

OK
I solved MPASMX, would it be better to use PIC-AS 2 ? but it's very big, it seems to me more than 2GB

[Anobium]

Excellent. Hopefully, it is seemless integration. If not.. we can fix.

MPASM v PICAS. For your old chip.... MPASM will work for you.

---

I have looked at the issue more.

1. create a hex using GCASM and then load in a PICKIT. The table is in the wrong locations in EEPROM. That is on problem.
2. The low(tablename) is also not working.

Please do #1 above and show me the hex loaded into PICKIT UI software.

[Anobium]

The extent of these issues are caused by the use of creating TABLEs in EEPROM. Other EEPROM read/write all worked ok.

The issue was deep inside the compiler. The following is not being treated correctly.

You would only see this if you disassembled the GCASM generated HEX in MPLAB!

MOVLW LOW(TABLECODE0) this gens 3005 MOVLW 0x0
MOVLW LOW(TABLECODE1) this gens 3000 MOVLW 0x0
MOVLW LOW(TABLECODE2) this gens 3000 MOVLW 0x0

should be

MOVLW LOW(TABLECODE0) this gens 3000 MOVLW 0x0
MOVLW LOW(TABLECODE1) this gens 3005 MOVLW 0x5
MOVLW LOW(TABLECODE2) this gens 300A MOVLW 0xA

---

These issues are resolved in build 1261.

Note: the ASM or .S was correct. These issues are in the generation process within the GCASM portion of the compiler.

Issue 1: GCASM was not correctly inserting the DATA in the HEX correctly. This is now correct. See the picture below of the error - the top screen shot shows the data being 0x00, 0x0A and 0x14.. should have been 0x00, 0x05 and 0x0A according the ASM. The bottom screen shot shows the DATA been located in the hex correctly.

This issue was a latent issue and may have been hidden for many many years.

; Data Lookup Tables (data memory)
    ORG 0x2100
TABLECODE0  equ 0
    de  4, 67, 79, 68, 69
TABLECODE1  equ 5
    de  4, 72, 69, 76, 80
TABLECODE2  equ 10
    de  4, 49, 50, 51, 52

Issue 2: GCASM was not correctly processing the location of the table(s). The top screen shot shows address 0x30, 0x40, 0x50 with the data from EEprom address 0x00. GCASM was not resolving the correct address for the table(s). This was caused by the implementation of PIC-AS ( 09/02/2021) when case sensitivity was required. The root cause was that GCASM internally is case sensitive ( the compiler is NOT case sensitive ) and the following conversion was failing.

movlw   low(TableCODE0)

Where the internal list of the ASM was in uppercase for the address but upper case of the table defition.

movlw   low(TableCODE0)


    ORG 0x2100
TABLECODE0  equ 0
    de  4, 51, 51, 52, 128

So, the address lookup to the Table(s) location was case sensitive... and, as the case sensitive search of the list returned 0 in every case! To resolve I have changed all TABLE entries to uppercase.

Issue 3

This was not related to your issue. On the 18F chips testing showed the ASM and the HEX produced was incorrect.

1. The ASM listing failed to correctly state the ORG location of the correctly. 18F locations need to align an even value. This impacted the production of the HEX by MPASM and the addressing failed. Resolved by ensuring the 18F align to 2.
2. The ASM listing failed to correctly address the EEPROM location. The 18F with EEPROM address requiring ADRESH:ADRESL would fail. Resolved by changing the compiler to test for ADRESH and to use a WORD address for EE operations.

---

A lot of work to resolve their issues.

Build 1261, or, greater, is required for all these fixes.

[Anobium]

12F629 showing the correct operation. Note: This uses test data as follows:

TABLE code0 Store data
    1,2,3,4
End Table
Table code1 Store data
    5,6,7,8
End Table 
Table code2 Store data
    "1234"
End Table

[Anobium]

18F - showing the EEProm after the test program has set the table and updated the EEProm.

; Data Lookup Tables (data memory)
    ORG 0x2100
TableCODE0  equ 0
    de  4, 51, 51, 52, 128
TableCODE1  equ 5
    de  4, 51, 51, 53, 0
TableCODE2  equ 10
    de  4, 30, 31, 32, 33

The pictures show the tables in the EEPROM window.

[Gigi]

Sorry but I was busy, I didn't do the tests you asked for.
I saw that you solved everything, very good and very fast, so now I can also use GCASM with the new 1261 fix, right?
Thank you very much

[Anobium]

Hopefully resolved. You will be the one to test in the wild.

https://1drv.ms/u/s!Ase-PX_n_4cvhM9CV9NzaOZkDEkRuQ?e=Ws2ZI1

I will remove this file in 24hrs.

[Gigi]

The link does not work

[Anobium]

Try https://1drv.ms/u/s!Ase-PX_n_4cvhM9CV9NzaOZkDEkRuQ

[Gigi]

Nothing, maybe the server isn't working and it's being updated, I'll try it later

[Anobium]

I just downloaded to my phone. how odd for you

[Gigi]

I tried many times, the link doesn't work. However I solved with MPASMX for the moment everything is fine.

[Anobium]

The Dev channel will have these updates in the next two days.

[Gigi]

Perfect

[Anobium]

Re changing the LInker to MPASM.. See this YouTube video. This will explain how to use, setup and modify the use of an extneral linker like MPASM or PIC-AS.

[Gigi]

YES, OK I learned this, I almost always use old pics so MPASM is enough for me but I ask you if PIC-AS also generates a more efficient and smaller hex, it would be useful.

[Anobium]

The DEV channel was updated this morning. If you restart GCSTUDIO you should get the latest toolchain with a fix in GCASM. Please use GCASM to test and ensure this is resolved for you and others ( in the future). My testing is never as good a real world validation.

---

Sorry, I did miss the smaller hex question.

The answer, with respect to the HEX produced, is the same machine code with the HEX file should be produced.

There may be checksum differences caused by the differing methods to terminate a record in the Hex.

---

In terms of optimisation/smaller HEX files. The ASM source, or .S source (which is derived from the ASM source) is the optimal source produced by the Preprocessor and the internal Optimization. If you have spotted, or know of, any further optimisation that code be applied then please do share.

This could Include things like not setting register when not needed, or the same for register.bits. I need an explaination of the use case including how to detect the use case. Then, we can discuss adding or not adding to GCBASIC

---

Hope this helps.

I am setting up a Patreon account next week. When set up please consider a donation to the cost of publication of GCBASIC. Current costs for 2022-2023 are £244 GBP. 2023-2024 will be substantially more as Certificatation costs have risen from £100 GBP to £350/£400 GBP. See https://sourceforge.net/p/gcbasic/discussion/579125/thread/f2fae2a6f0/?limit=250#8256

I will be asking for support money in October, as I do every year. This is an early heads up for the size of the support costs.

Evan

[Gigi]

Finally I managed to update, I selected DEV channel (I have to leave the selection like this).
Everything works fine.

I was just asking for information to optimize the code, I'm not able to give you help to improve the asm code, I'm just trying to be thrifty in the GCB code and variables.