| View previous topic :: View next topic |
| Author |
Message |
Markdem
Joined: 24 Jun 2005
Posts: 206
|
| Debugging Help |
 Posted: Sun Aug 08, 2021 12:30 am |
 |
|
Hi All,
I have a odd issue that I can't seem to debug, wondering if someone else can see what is going on. Bit of a long story, sorry..
I have a program, quite long at a few thousand lines, been running for years. I now need to change it and a single global variable (1 byte) needs to be added.
When I add the var, pic will reset when ethernet has link. The var I added has nothing to do with the ethernet stack or reading from flash, and at this point all I am doing is setting it to 0.
After a few hours of debugging, I found the following;
1. Driver for ENC28J80 has a var called "NextPacketLocation" - Address=0x195, defined as global at the start of the driver.
2. Driver for reading a MPFS formatted EEPROM has a function called MPFSGetEnd(MPFS* handle)
3. I am calling the above, in a funtion that has nothing to do with ethernet, giving it a pointer address of 0x842, pointing to 0x2195
4. The last line in MPFSGetEnd is
| Code: |
*handle = (_currentHandle+MPFS_Start);
|
The data in *handle gets set fine, but for some unknown reason the data in NextPacketLocation gets changed at the same time. If I break before the above line, NextPacketLocation = 0x00. Step over the line and NextPacketLocation = whatever was in _currentHandle (Address=0x1C7)
The next time ENC28J80 gets read the "NextPacketLocation" will be some address way past any buffer inside the ENC28J80, read fails, the function that did the read checks the frame, sees that it is invalid and resets the PIC. Mistory reset has been found, but I have no idea why the memory location is been touched.
The screen shots of the debugger showing data and addresses are;
Before [img]https://1drv.ms/u/s!AjN1dYoUGyAvh_ZV6yuV0D9z8rFPag?e=CgIjhy[/img]
After [img]https://1drv.ms/u/s!AjN1dYoUGyAvh_ZU6uhIys0cjVFDDA?e=iAATOb[/img]
If I comment out the "*handle = (_currentHandle+MPFS_Start);" call the issue with the restarting if fixed, so I assume it has something to do with this. Reads from flash don't, but that is to be expected.
If I take my newly added variable out, everything works again.
I have tried to change the optimization level to 0, no effect.
Can anyone help me out here?
Thanks |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Sun Aug 08, 2021 5:05 am |
|
|
I don't know..but...
how much RAM is left with the new compile ?
what happens if you add 2 or 3 dummy variables ?
does it fail if you 'preset' the variable ?(all RAM has unknown data in it unless YOU preset it )
while it's a byte, it's added to another variable and stored into a 3rd....maybe change it to the same type ( 16 bits ?) as the others ? It could be a 'casting' problem ??
since the program was running fine I suspect something 'silly' and so obvious you can't see i. BTDT, way too many times.
Jay |
|
|
Markdem
Joined: 24 Jun 2005
Posts: 206
|
|
| Posted: Sun Aug 08, 2021 6:45 am |
|
|
There is 34% ram left in both versions. I did not pay too much attention to the exact number.
When I started the modifications I added 6 new variables to the code. I cut back to one to aid in debugging.
Yes, the new variable was been set to "0". I do this in general as I have been bitten to many times with odd bugs because of uninitialized vars.
Not sure what you mean with the last part. Nothing in the code has been changed. All I have done is made a new global variable and set it to 0. Nothing at all has changed anywhere.
I just don't understand how a simple call like "*handle = (_currentHandle+MPFS_Start);" can be changing 2 different, not even close, memory locations.
Just a quick thought. For debug I have this;
| Code: |
delay_us(1);
*handle = (_currentHandle+MPFS_Start);
delay_us(1);
|
However there is code prior to the first delay (the delays are just there so I can attach a breakpoint on them).
Is there a chance the debugger\MPLab is not actually displaying that is in "NextPacketLocation" at the time. EG, code before the first breakpoint is changing NextPacketLocation, but it is not been updated in MPLab untill the second breakpoint?
I have worked around this issue by not getting the handle in the one place that this is causing the issue as I do a close right after it anyway (just reading one icon bitmap). Funny that it is only one function that has this issue. Other functions call "MPFSGetEnd" without a issue but I can see any differences, or why adding a variable would do anything like this. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 08, 2021 8:46 am |
|
|
Add two new sequential byte variables (instead of one) and see what happens.
What is your PIC ?
What is your compiler version ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sun Aug 08, 2021 9:56 am |
|
|
Also what are the definitions of the MPFS type?.
The thing 'leaping out', is that the pointer is "pointing to 0x2195", when the
other variable is at "Address=0x195". Suggests bank switching is not
being handled correctly somewhere. There are bank issues with some
compiler versions. Hence compiler version, and CPU type are critical things. |
|
|
Markdem
Joined: 24 Jun 2005
Posts: 206
|
|
| Posted: Sun Aug 08, 2021 5:52 pm |
|
|
PIC is 18F67K22
CCS v5.071 (Yes, I know it is old...)
PCM Programmer - I tried to add "int test[2]", still fails. I am guessing this would make concurrent variables. One thing to note is I can add local variables to a function without a issue, it is just global that make it fail.
Ttelmah - def of MPFS is simply "typedef DWORD MPFS;". This is the ccs port of the microchip IP stack.
The bank switching idea sort of makes sense, but why would the data at 0x2195 still be set correctly? Unless there is a timing issue with the debugger, it looks like both memory locations are been set at the same time.
I have cut down the function that is the issue of all this.
You can see the commented out call to MPFSGetEnd. If I try to return the handle, the "NextPacketLocation" will be overwritten with the data in handle.
| Code: |
void glcd_bmp(char* file)
{
MPFS handle;
handle=MPFSOpen(file);
if (handle != MPFS_INVALID)
{
MPFSGetBegin(handle);
//MPFSGetEnd(handle);
MYMPFSGetEnd();
}
MPFSClose();
}
|
The whole MPFSGetEnd(handle) and MYMPFSGetEnd is:
| Code: |
void MPFSGetEnd(MPFS* handle)
{
XEEEndRead();
// delay_us(1); NextPacketLocation=0
*handle = (_currentHandle+MPFS_Start);
// delay_us(1); NextPacketLocation= whatever is in _currentHandle. MPFS_Start is always 0.
}
void MYMPFSGetEnd()
{
XEEEndRead();
}
|
XEEEndRead(); is just "#define XEEEndRead()". I think it is simply there to make the Microchip port work. I assume I don't even need this.
MPFSGetEnd is used in other parts of the code and works fine. It is just in mu glcd_bmp() where it fails..
Thanks again. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Aug 09, 2021 1:06 am |
|
|
Er.
I'm not surprised it is giving issues......
| Code: |
MPFS handle; //Handle' here is a dword value
handle=MPFSOpen(file);
if (handle != MPFS_INVALID)
{
//You don't show how 'handle' is declared in this call. Same
//comment may apply.
MPFSGetBegin(handle);
//Your declaration of this has handle here being a
//'pointer', but you are not passing a pointer, just a DWORD
//MPFSGetEnd(handle);
MYMPFSGetEnd();
|
If a function uses a variable as a pointer, then it needs to be passed
a pointer.
MPFSGetEnd(&handle);
Pass the pointer to handle to the function. |
|
|
Markdem
Joined: 24 Jun 2005
Posts: 206
|
|
| Posted: Mon Aug 09, 2021 1:32 am |
|
|
Ahh crap, you are right... I just did not paid attention to it has it has worked now for about 4 years.. Thanks for pointing that out.
In saying that, why did\does it work if I take the new variable out? Even if the memory location that was been "pointed" at by handle was not been used, NextPacketLocation would be reset to 0 and the ip stack would not work..
MPFSGetBegin expects the handle, not a pointer so that is all good.
Thanks again. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Aug 09, 2021 9:46 am |
|
|
The old thing of luck.
What must have been happening was the number in 'handle', just
happened to point to something that didn't matter. Adding any variable
changes the position of everything afterwards. Disaster.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
