16F886 running out of SRAM ?

[Chris Barron]

I have ported a project from the 16F690 to the 16F886 to gain more memory codespace, and have benefitted form getting more ram too.

The datasheet says I have over 300 bytes of SRAM, but as I've got to about my 70th byte of ram I have started to get problems with the chip stopping.

I have an assembly interupt running (well established code I've used many times), the code enters the interupt, resets the one second flag properly and exits cleanly, but ponly on the first interupt, thereafter it crashes.

Are there any issues with accessing the whole ram codespace ? Am I missing something like as if I should be taking responsibility for bank switching and so on.

I had a similar thing happen to me with a pic which had 128 bytes of ram, I ran out of variables at about 70 or 80 (due to the pbp overhead) but didn't expect to run out so soon with over 300 bytes of sram.

I would appreciate any help with this because I'm really stuck.

The reason I need so many variables is because I'm doing a lot with arrays/scrolling messages and menu items on a 2x16 lcd running a menu system, so there's lot's of pointers and screen maps etc. required

Thanks in advance
Chris

[rmteo]

I have moved this post to a new thread in the "Off-topic" forum as it is somewhat off-topic.

[Archangel]

* * * * No Fire Suit Required * * * *
The opinions expressed above are a welcome dissertation by their author.
* * * * Only problem I see is 24 series PIC <> supported in PBP * * * *

[rmteo]

MicroChip does offer a free C compiler. If you are a BASIC afficionado (like myself), mikroElectronika do have a BASIC compiler for the PIC24 and dsPIC30/33.

[Chris Barron]

I have moved this post to a new thread in the "Off-topic" forum as it is somewhat off-topic.

No yopu mean you appear to have deleted it, because it isn't in the off-topic forum......either way, any idea what the problem may be ?

[Melanie]

Check your code. You may have a jump back from your ISR instead of a RESUME. You might have a jump out of a subroutine instead of a RETURN. Whole heaps of minor things like this which are easily missed can cause your program to crash unexpectedly.

If you run out of RAM, the Compiler will tell you at compile time that you've used up all you're allocated, so it leads me to suspect you're doing something illegal in your code...

Since you're using arrays a typical mistake is to allocate say 64 bytes of RAM for an array...

MyArray var Byte (64)

... and then trying to modify MyArray(64) forgetting that the legal count is from 0-63, and byte numbered 64 (which you can access) does not belong to your array.

CHeck IF/THEN statements that access arrays are counting within the legal limit and not accessing bytes outside the defined array.

On the plus side, I have code that uses large amount of RAM on various 16F and 18F parts without issues (though not on that particular chip you've mentioned).

[Chris Barron]

Check your code. You may have a jump back from your ISR instead of a RESUME. You might have a jump out of a subroutine instead of a RETURN. Whole heaps of minor things like this which are easily missed can cause your program to crash unexpectedly.

If you run out of RAM, the Compiler will tell you at compile time that you've used up all you're allocated, so it leads me to suspect you're doing something illegal in your code...

Since you're using arrays a typical mistake is to allocate say 64 bytes of RAM for an array...

MyArray var Byte (64)

... and then trying to modify MyArray(64) forgetting that the legal count is from 0-63, and byte numbered 64 (which you can access) does not belong to your array.

CHeck IF/THEN statements that access arrays are counting within the legal limit and not accessing bytes outside the defined array.

On the plus side, I have code that uses large amount of RAM on various 16F and 18F parts without issues (though not on that particular chip you've mentioned).

Thanks for the reply

I've stripped back everything from the code to just the ISR (assembly) and the code which checks for a 1 second epoch (flag is set during ISR)

I can add lots more vars now, so presumably something is wrong with my structuring which I'll have to work on by reintroducing the other subr's one at a time, but at least that's a start.

I'm also using both pwm output channels independently of one another, a 2 x 16 lcd display and a rotary encoder so I've missed a step of something out I reckon !

Best Wishes
Chris