Matrix user forums

Hi all,

I have a problem I can't fix, asking for help.

My project uses a PIC16F886 because I need the memory space, 0x1fff (8k).
Trouble is, as soon as my .hex grows beyond 0xfff I get erratic operation; the program just hangs somewhere after it does something:
The program is driven by switch- and encoder inputs. Some inputs will give correct reaction, but after a specific input, at a specific program state, it hangs.
If I re-organise the program, so that (I guess) the various parts end up somewhere else in mem space, it hangs somewhere else. If I cut out parts so that the hex is smaller than 0xfff, I have no problems at all.
I had one example where the addition of a known-good macro (set the cursor pos on an LCD) caused the problem to appear.
The .fcd of the '886 does have the correct mem boundary limit as far as I can see.

What could it be?

tia,

jan didden
Linear Audio

Hello Jan

Could be that some of the memory on the chip has been locked or corrupted after a certain point which is causing your program to hang. Have you managed to replicate the problem on a second device?

Hello Ben,

Same with another device.
But now I played around some more, and I also have the problem with a .hex length less than 0xfff (0xfd7)....
Now I'm lost. Hmmm....

jan didden
Linear Audio

Is there a way to check max stack depth my program gets into?

jan didden
Linear Audio

HI Jan

Good thinking, I dont know if there is any way to find out how many stack levels you are using without manually going through the assembler code. Though there is probably a tool that will do this for you out there.

You should get a compilation report from your compilation output if the stack is being compramised.

Call Stack Usage Report
=======================
main and Task(s): hw used:8, sw used:0
interrupt: hw used:2, sw used:0"

If you are getting a similar message then you can try switching on the boostc software stack and see if this fixes your problem.

Hmmmm. Switching the linker option -swcs on (software callstack) doesn't make any diference.
Can't find any indication of stack usage in any of the output files. Only found this:

Memory Usage Report
===================
RAM available:368 bytes, used:211 bytes (57.4%), free:157 bytes (42.6%),
Heap size:157 bytes, Heap max single alloc:95 bytes
ROM available:8192 words, used:4537 words (55.4%), free:3655 words (44.6%)

Don't see anything unusual here.

Any other ideas?

jan didden
Linear Audio

Still have this iddue, it's a major pita, looks like I have to redesign somehow the software or get another processor or what.

Could it have anything to do with a subroutine straddling the magic 4k (0x1000) mem boundary?
Any ideas at all, anybody?

jan didden
Linear Audio

Hello Jan

PICs do handle memory quite strangely but this should not effect the program memory structure. I am also at a bit of a loss as to why your program is not behaiving correctly. Are you using the watchdog timer or any special interrupt routines that could be causing glitches or problems. Also look out for calls to things like component macros that are inside your main loop and an interrupt. If a non re-enterant bit of code is called from the main and then stopped halfway through for an interrupt that then calls the same code then this could cause the problem you are experiencing. You should get a warning about this if this is the case though.

Aha, some more info:

I took the .asm from Flowcode and assembled it with MPASM.
Got this warning:

Warning[220] [filename]: Address exceeds maximum range for this processor.

Hmm. On to the data sheet:

"The PIC16F882/883/884/886/887 has a 13-bit program
counter capable of addressing a 2K x 14 (0000h-07FFh)
for the PIC16F882, 4K x 14 (0000h-0FFFh) for the
PIC16F883/PIC16F884, and 8K x 14 (0000h-1FFFh) for
the PIC16F886/PIC16F887 program memory space."

Now do the hex download with PICstart+, and check address range:

"Device Type: PIC16F886
Address Range 0-12d7"

What's going on here??

Edit: Maybe check pageing in Flowcode for this processor?

jan didden
Linear Audio

Hello Jan

Could it be something to do with the definitions for the programmer you are using?

Flowcode has the chip size down as 14336 bytes which represents 8KB of 14-bit program memory. This is however currently only used by the Speech component to allocate the memory.

I have also checked the BoostC compiler definitions that are included with v4 and this is stating the address range as 0000h -> 1FFFh so this also seems to be correct.

Maybe its worth seeing if there is a new version of MPLAB available.

Well, it gets weirder.
ANYthing from Flowcode that I assemble in MPASM gets the max memory exceeded warning, it seems.

I tried a known-good program of some 0x600 bytes in a 16F690 which has 0xfff memory, and another one that has 0xd17 bytes into a 16F886 with 0x1fff memory and in a 16f884 with 0xfff memory and in all cases I get the max memory exceeded warning.

The programmer shows the correct end-of-mem location without balking in either of the cases I tried.
So now I think maybe MPASM is buggy here.
Also, the program that hung, I deleted lots of stuff so it's less than 0xfff and it now runs fine, even with the max memory warning messages.

I'm running out of ideas.

jan didden
Linear Audio

Hello Jan

I just looked in the following directory "C:\Program Files\Microchip\MPASM Suite\LKR"

and there are files in here which specify the memory range of the device. My files appear to be correct though.

CODEPAGE NAME=page0 START=0x0 END=0x7FF
CODEPAGE NAME=page1 START=0x800 END=0xFFF
CODEPAGE NAME=page2 START=0x1000 END=0x17FF
CODEPAGE NAME=page3 START=0x1800 END=0x1FFF

Might be worth checking yours to ensure that everything is ok. Certainly is a strange problem.

Would be good to send the program via our EB006 and seeing if it has the issue. If it is easy to spot the problem with the program then you can PM me your Flowcode file if you like and I will try it out here on a 16F886. This would then rule out Flowcode as the culprit

Ben,

I had a discussion with a few guys over at the microchip forum. What we found was that the max mem exceeded message is triggered by writing the ID and config locations in the PIC. These are eeprom locations up in the 0x2006 range, which are technically speaking out of max mem range. For some reason, MPASMWIN flags them as mem exceeded. So it seems that the warning will appear with any PIC no matter what, and can be ignored.

Thanks for your help, just to be sure I'll check those codepage limits anyway.

jan didden
Linear Audio

Hi Jan

Well thats good to know but back to square one. If you do want me to try your program on our hardware then let me know and I will look into it for you.