Problem with 18F2520 and Mikroc?

[davegsm82]

Over the past couple of days I've been experiencing problems with my 18F2520 using Mikroc.

I've written code for a Geiger counter project using a Nokia 3310 LCD screen, 3 push buttons (port C and port B using an interrupt) PWM driving the HV generator, GM pulses coming in on RB0 interrupt. RS232 for PC communications and I2c for the clock and EEPROM storage and a buzzer on port C also.

The code is quite large, about 80-93% of the PIC's capacity depending on whether I leave in or out the code described next. The problem I'm having is that if I leave in my 'Bytehandler' function which processes commands from the RS232 port then I get very strange behaviour, even though the function is not being called!

The function is quite large but does not access any ports or pins, simply looks at data stored in a string and acts upon it accordingly.

I think it may be to do with the size of the code rather than the function itself. However this is the only function i can omit while maintaining the basic functionality of the system.

With this function left in, the PIC acts as if you are pressing the 3 buttons randomly, and I mean completely randomly. Could be seconds or minutes between each phantom press. Also it randomly thinks it is receiving data on the RS232 even though nothing has been sent. Also sometimes data on the screen becomes corrupted, as if there is some sort of memory overflow into other data areas. For example the Counts per minute data may suddenly jump from 30~60 (normal) to 300000+ (Nuclear war) and also spits out random characters on the LCD.

With this function left out, the project works perfectly. No strange behaviour.

If i leave the function in, but omit say, half of the string compare functions then it runs ok.

Is there a known issue with the 18f2520 and Mikroe? Is there anything else I can try to troubleshoot this?

I've not sumulated this as I have the hardware built and don't have proteus.

[Mince-n-Tatties]

have a look at this thread

http://forum.mikroe.com/viewtopic.php?f ... mlkchecker

[davegsm82]

Hi Mince,

I've downloaded and run the MLK checker, unfortunately the 18F2520 wasn't listed however I've 'fixed' the files that were listed.

Anything else you can think of?

Cheers, Dave.

[Mince-n-Tatties]

Anything else you can think of?

This is the type of problem which would at the very least require access to the full project and at the very best, full project plus the hardware it is to run on.

You describe what is typical when variables are confused or a boundary is overrun. This can be through incorrect device RAM/FLASH setup (hence the link), Compiler bug, Device errata, incorrect type def, etc.

Make sure you use the volatile def where needed. Make sure to leave the compiler optimization level at 4.

ALWAYS check device errata
http://www.microchip.com/wwwproducts/en/PIC18F2520

[paulfjujo]

hello,

The code is quite large, about 80-93% of the PIC's capacity

and what about the free available RAM ( %free or % used) ?
and buffer size for RS232 data receiving ?

And you don't have any problem with PWM Hihg voltage management ?

[davegsm82]

hello,

The code is quite large, about 80-93% of the PIC's capacity

and what about the free available RAM ( %free or % used) ?
and buffer size for RS232 data receiving ?

And you don't have any problem with PWM Hihg voltage management ?

Hi Paul,

It's using about 60% of the RAM. All ram usage is declared in the main body of the code, so I'm not calling functions which then wipe out huge sections of RAM.

The RS232 buffer is 40 characters, this is excessive and I plan to reduce it, however at the minute it simply fills up with AT+ commands until the <CR> byte [enter] is received (then the bytehandler is called) OR until it is full, at which point it is flushed with 0x00.

Ok, with regards to PWM'ing. The HV control is slightly jittery, the average tube voltage on my system is about 430v, it regulates reasonably well between 418 to 422, constantly hunting to keep the voltage right because of the PWM resolution. It monitors the voltage directly on one of the A/D channels through a voltage divider, using the full 10 bits A/D and 1V/Bit gives a max readable voltage osf 1023V. This is perfect because some of the tubes I use require up to 800V.

I couldn't work out if the Mikroe library gave 10 bit PWM resolution or just 8, so I use the PWM_Set_Duty() function to set the 8 bits and I also use CCP1CON.DC1B1 and CCP1CON.DC1B0 to ensure I'm getting the full 10 bits for fine tuning the voltage.

Dave.

[davegsm82]

I couldn't work out if the Mikroe library gave 10 bit PWM resolution or just 8, so I use the PWM_Set_Duty() function to set the 8 bits and I also use CCP1CON.DC1B1 and CCP1CON.DC1B0 to ensure I'm getting the full 10 bits for fine tuning the voltage.

Dave.

And as I wrote that I stopped to think, today I have realised that in the 2520 the PWM resolution is only 8 bits and the lower 2x bits are not implemented. This doesn't cause any problems but it's a shame because I've already built the (admittedly, prototype) hardware and can't wedge a 4520 in just yet.

To get the regulation a little better I have expanded on the 2 bits and made a 3 bit variable which I then use to reinitialise the PWM frequency at 8 values between 3000Hz and 3084Hz while maintaining the PWM duty cycle. Changing the Frequency gives that extra resolution needed to keep the voltage stable despite the limitations of the 8-bit PWM.

Dave.

[p.erasmus]

I have realised that in the 2520 the PWM resolution is only 8 bits and the lower 2x bits are not implemented. T

Where did you see this ,I never saw only 8 bit resolution on a PIC they are standard 10 bits for PIC18 and higher for PIC24/dsPIC33
I found this in the PIC18F2520 datasheet would be nice if you can show where you saw the 8 bit resolution

[davegsm82]

I have realised that in the 2520 the PWM resolution is only 8 bits and the lower 2x bits are not implemented. T

Where did you see this ,I never saw only 8 bit resolution on a PIC they are standard 10 bits for PIC18 and higher for PIC24/dsPIC33
I found this in the PIC18F2520 datasheet would be nice if you can show where you saw the 8 bit resolution

Hmm. Yes, it would be very nice if I could find it now, but I can't seem to make that happen. I'm now very confused, however I have realised that I made a silly mistake when I was trying to set the PWM, I was setting the lower bits of CCP1, not CCP2 which is the one I'm using *facepalm*.

Ok, well one other thing I've noted is that the PWM value that you set in the MikroE library only has a resolution of 8 bits, as you can see from the attachment... This may be what got me thinking about the resolution and I may have been looking for something that wasn't there.

I was sure that I saw in the datasheet that in the 28 pin devices the lower bits are not implemented but I may be very wrong.

Dave.

[p.erasmus]

Well yes that is one of the old quirks of mE libraries they are not very useful and that is true the mE library only supports 8 bit resolution but that is not the case
of the chip itself

[davegsm82]

I'm coming back to this project now after a while and would like to try and get to the bottom of this somehow.

Is there anything that anyone can suggest I can try? obviously I can't duplicate the hardware for everyone, and I don't know if it will simulate correctly, but I can upload my (as far as I can tell, correct) code if necessary.

I have the PWM stuff working correctly now, the voltage regulation is almost perfect, it's just the whole random operation/possible RAM overflow problem when I edit in a call to a function that takes me up to 89% codespace usage (can't remember RAM usage but I think it's about 60%).

Can anyone help walk me through this issue?

Thanks, Dave.

[davegsm82]

Anyone? I'm being driven mad by this little project that has been dragging on for a number of years now. I can only assume that this is a variable overflow into somewhere it shouldn't, since it acts like someone is pressing buttons when they aren't etc.

Would it help if I drew up (literally, pen and paper) the schematic and posted up the code?

[oliverb]

What about name collisions? Are there any variables with names that only differ by case but are spelled the same?

[davegsm82]

Hi Oliverb,

Sorry for the late reply. No, i've checked all variables to ensure that they are individual to functions and those that are used globally aren't overloaded or anything like that.

This is driving me insane.

Dave.

[Sparky1039]

For what it's worth you might try this. Reorder all your variable declarations by size starting with the largest to smallest. This applies to constants, floats, globals, and local variables. Same applies to members within unions and structures. It may be a bit of work on your part to do this, but I have encountered unexplainable anomalies in the past when my variables in the order of declaration were random in defined size. Reordering eliminated most of my anomalous problems when I encountered them. It seems mikroC can loose track of the variable addressing when pushing the limits sometimes. I noticed it more when working on larger bit processors. It seems that when the natural memory bit size is greater than 8 and you are declaring variable sizes willy-nilly, the compiler isn't as efficient in allocating precious memory space, especially when you have used up most of it. HTH