#LOCATE usage

[Guest]

Hi,

In my previous post (weird behavuar) I asked about some weird errors like corrupted string output and restarting or not starting at all on my
pic 18f8720. Some of the answers suggested to use a new chipset so we did a revision to A4 silicon.

Well, first it didn't start with several compilations so I tried a super simple compilation like this
main()
{ while(1) fprintf( DB9, "hi" ); }
That didn't work either until I removed this line:
#ZERO_RAM

Finally it started so I tried my normal version(88% rom). It started as well but again with weird errors like corrupted strings or no response with RS232. I have no clue what's wrong but the last big chance I did was using #locate for all global variables. Someone suggested to put all small variables in to memory bank0 and all large stuff(array's) in bank3 and higher so I did that. But no results. In fact, I have the feeling that #locate only makes it worse. On the A3 version, some compilations didn't work until I removed the #locate lines.

Maybe I'm using it wrong?

[Guest]

In addition:

I asked about locating local variables but that gives compiler errors, or I'm doing it wrong:

[Mark]

I wouldn't use the #locate. If you screw up and locate one variable at an address that is used by another, you will drive yourself bats. This would be especially true with arrays, and even more so if you think you will ever change the size!

[Guest]

Well, if the memory management was 100% correct I wouldn't bother myself with this stuff either. But someone told their was something wrong with the memory management gave some tips I followed. Maybe it's not nescesary to use this indeed, I don't know. I'm trying all kind of stuff to fix these weird bugs. Luckily I don't use malloc or dynamic memory so it makes it a little bit more easy.

Greetings

[ckielstra]

#locate is a kind of pre-processor command, when CCS would have been a proper compiler it would have had a linker/locater and you would have placed a locate commands in the linker/locater definition file.

The #locate command will not work on local variables, so that explains your compiler errors.

The reason why you were told to place the larger variables is because of the bank switching architecture of the PIC processor. The PIC processors can access the variables in bank0 more easily than in the other banks. The CCS compiler does a great job in inserting and optimizing all the bank switch commands but, just sometimes, it makes an error.... #locating your large buffers at the end of memory will create more memory in bank0 and so minimizing the number of bank-switch commands. With less bank-switching commands the chance of this type of errors becomes smaller. It is also a good way of optimizing your code.

Remember, there is only a small chance this is the kind of error that is causing your problems. Especially your mentioning of the processor restarting is very strange, this can only be caused by a watchdog trigger or an instable power supply.

Use #locate sparsely. Manually locating variables is a lot of work and can cause other errors as well (overlapping variables......)

I would suggest to focus at the restarting processor first as this is such a rare type of error but pointing to a low level kind of error. If your base isn't right everything build upon it will collapse. Do a test with disabled watchdog and hook an oscilloscope to the power pins of the processor to check for voltage dips. Implement a way to log a message on power up showing the reason for starting up, see the function restart_cause(). This might give an answer as to why the processor is restarting. If your processor has a #BOR fuse (Brown Out Reset) then activate this one for detecting power supply dips.

Edit: I just see you already have the watchdog disabled and the brownout fuse enabled.

[ckielstra]

The trick in finding errors is always to remove as much as code as possible until you end up with a small program that still generates the same error. You continue this process of removing code until you have one function or even one line of code that is causing your troubles.

Problem in your situation is that the error is not occuring at the same location everytime. Those are the hardest to find errors.

Above you described a small test program that failed, you fixed it by removing the #zero_ram directive. Maybe you should return to this failing version, just because it is so small and failing it is the kind of testprogram you are looking for!
#zero_ram generates quiet a lot of code with loops I suspect. This failing is another pointer to an hardware problem.

What voltage is your circuit running? And, I mean, not the designed voltage but what you meassure at the processor pins?

What is the brand and type of crystal you are using?
What are the type and capacity of the capacitors next to the crystal?

[Guest]

Thank you very much for detailed help! Maybe a failing power supply could couse this errors? To be honest, I don't have much knowledge of hardware, just programming some new ideas in an existing device. I like to answer your questions about the crystal and stuff but therefore I must ask the hardware guys at my work for help. Hopefully I can answer this tommorow.

Anyway, the restart-error sound logical to me, although the pic gets some backup power so if you pull out the power, it still remains active for a few seconds. The LCD screen doesn't flicker either and with the new A4 silicon thingy, I haven't noticed restarts, except that the system didn't start at all. I'd say the behavuar really depends on the compilation on the pic. Errors such as hang-ups didn't happen randomly at the initial fase. But the weird thing is that the code is correct and changing or adding something stupids like fprintf(..) often 'solves' the problem (or moves the problem elsewhere). What kind of hardware/power supply errors could cause that?

You're right about the small version, its perfect for testing purposes. It found out that #ZERO_RAM isn't the main cause. But maybe its the combination with the use of #LOCATE:

#LOCATE's #ZERO_RAM Result
disabled disabled it works
disabled enabled it works
enabled disabled it works
enabled enabled doesn't start

I'll try to give the information about the power supply tomorrow, now I need some sleep otherwise I'll turn insane with these bugs!

Greetings

[ckielstra]

[Guest]

Hi again,

First about the supply and stuff:
>but what you >meassure at the processor pins? What is the brand and type
5 voltage power supply and the processor pins shouldn't be higher than that.

>of crystal you are using? What are the type and capacity of the
>capacitors next to the crystal?
10 MHz crystal and 15pf load capacity

And we don't have a Circuit Debugger.

I was thinking about data corruption as well, especially with the corrupted string occasions. But its weird as well that corrupted versions can give wrong output right at the start. At that point no pointer errors or array filling shouldn't have happened yet. And also printf with constant string parameters are messed up. Sometimes completely, and in other cases there's an extra character added. For example:

[ckielstra]

[ckielstra]

[Guest]

>In my opinion every professional organization can't do without.
Maybe we have one at the office... I should ask about it. Mostly I'm programming this thing at home.

And yes, their is 1 timer used, gives an interrupt every second. I was concerned about that as well and if I remember right, the compiler gives a warning about that. I don't have the code here right now (I'm hanging around at school) but I'm pretty sure that #INT...fast is used 1 or 2 times. It's worth checking the system without the timer, although we need it in the end. Could it be that there's too much code inside the interrupt event? If the timer is causing havoc, we need a work around somehow. Thanks for noticing that. As I said, I will fix a small version for posting here tonight.

Bedankt! (I see you're from the Netherlands, me too)

[ckielstra]

Hoi

For normal interrupts the CCS compiler will save and restore all registers. The CCS compiler has poor support for the Fast interrupts; you yourself will have to take care of saving and restoring all registers that are modified in your interrupt.
I suggest you check the generated list file for the Fast interrupt. Look at all the modified registers and make sure they are saved on entry and restored on exit of the interrupt routine. Also be aware that the CCS compiler uses the memory addresses in the range 0 to about 5 as scratch registers; you will have to save and restore any of these modified registers as well (my guess is that this is where your problem is.....)

[Mark]

First ask yourself do you really need the fast interrupts. Maybe stick them as normal for testing. BTW, how are you programming this thing. It must be incircuit but with what? About those RS232 errors, the compiler uses the clock define to figure out what to set the baud rate divisor so listing it incorrectly could cause a problem.

[Guest]

Hi,

I was wrong about the fast interrupts. We don't use them. But maybe its better to take a look at the code: