banking error adressing arrays

[pjmylle]

Here again with another compiler issue.
When accessing the digits array, the compiler makes a banking error.
The array is located in memory region 0x0BC to 0x0BF.


This is the code that I'm currently debugging.

According to the simulation software (that has the same result as the hardware) the BSR register is set to bank 1 but the variable is in bank 0.


The used version is IDE version 2.0.3.3, loader 1.0.3.2, installed update 4.0.3.8.
The bank bit was set when a variable was adressed in the 0x100 memory location but was never cleared when a memory location was adressed in the lower bank. Then it was messing in the wrong memory location.

Is there any work around for this? Don't even know it the previous bug I found is fixed. Havent tried it with this version of compiler as I moved to the pic18f as I ran out of program memory. Irronically it was for the same project that I'm trying to finish now.

[trastikata]

The used version is IDE version 2.0.3.3, loader 1.0.3.2, installed update 4.0.3.8.

Hello, is there a reason for not trying with the latest compiler update? You are at least several updates behind.

[pjmylle]

The updates are not applicable to the chip I'm using.
Only added controllers with almost every update but none of the updates for the new 'to be payed' upgrade corrects for RAM bank issues.
So why pay and update if the reported bugs are not fixed but the reports are removed? I'm referring to the anomaly I made and last visited on 31-12-2023 18:01 with link https://protoncompiler.com/index.php/topic,1731.0.html which is now missing. In this report I linked to my other thread which described the error in detail.

I just rechecked this bug I found in my previous thread with my current compiler version I'm using and the bug is still present.

[CPR]

Which 18F PIC are you using? (and what was the previous error that's missing?)

[pjmylle]

I'm using the 18F2520.
The issue seems to be bypassed by using the "Auto_Heap_Arrays = on". Then all the arrays end up on bank 1 in memory. So if the compiler forgets to reset the bank and it stays in bank 1 there's no issue. I wonder how many of these bank errors could happen in my program. So far I have only found this one and the program is working as intended with the auto_heap_arrays = on.

The previous error that I had was om the 16F886. When the routine "context save" is called it pushed registers into memory (in the context_store variables). By doing so it set the IRP bit (status.7) if these variables are in the higher memory banks. The user has no control over this as these context_store variables are places after the user made variables by the compiler. After it saved the registers for the ISR, it doesn't reset the IRP bit. When the user then uses arrays in the ISR (like for storing EUSART received data or sending data) and this array is in the lower banks of the memory, the controller is in the wrong memory bank as the IRP bit is still set. A work around for this it to manually reset this bit after the context save function. You can find alll the details in my other thread (https://protoncompiler.com/index.php/topic,1724.msg13504.html)

[CPR]

Thank you pjmylle. I'm using a 18F25K22 in a current project, makes me wonder if that's also affected. Hopefully there'll be a fix for both issues soon. Les?

[top204]

Without seeing the full program I cannot give a real answer. However, remember, PIC18F devices have Access RAM, so if a variable is in there, it does not matter what the BSR SFR holds.

The compiler handles RAM banks extremely efficiently, and with great care, but nothing on this earth is fool proof, so if you can, can you send me a message with the full, and compilable, program in it so I can go through it.

[pjmylle]

I can imagen that handling the RAM banks is a nightmare on itself.

Code has been send to you Les.
If you want me to run further simulations, let me know.