View previous topic :: View next topic |
Author |
Message |
Andreas
Joined: 25 Oct 2004 Posts: 136
|
some strange behaviour with Vers 5 Compiler |
Posted: Tue Oct 01, 2013 7:27 am |
|
|
Hello Friends
Since days i am now struggling with a funny behaviour.
Program was built years ago and is running very stable.
Have to Change now some parts, everything works perfect, but if I insert some new code the program starts hanging in a Loop which can not be traced by the Debugger !
After searching for hours I found out that the program Loops in the Memory area 1FD30 with about 3 steps and never Ends from there.
The obviously seen reaction at my Hardware is that it is not updating a lcd Display.
After removing the code the program runs as be before !
As can not see a specific reason in the code i stepped down to a single line which is just a simple if then, with changing the character in the is Statement it works again !
I am really messed up now, because I can't get my Project in a stable working condition
any ideas friends ???
best regards
Andreas (Vienna, Austria) |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Tue Oct 01, 2013 7:48 am |
|
|
Since program was done 'years ago' and worked fine, I'd go back to the compiler version it was created in.
Why did you 'upgrade' to V5? It's unlikely it has any real features that your old program/PIC could take advantage of.
I'ld need more details(PIC type, code segment that fails, etc.) to supply more help.
Bottom line..I'd go back to V4.xxx that DID work !!
hth
jay |
|
|
Andreas
Joined: 25 Oct 2004 Posts: 136
|
|
Posted: Tue Oct 01, 2013 7:57 am |
|
|
Hello Jay !
In some Points you are right, going back should be a good Point, unfortunately i am already using the new rs232 Buffer functions, thats a very good Feature for not loosing incoming chars.
As for now, its really strange, program was working today, then Change some small issues and boom its blowing up in a way that makes it impossible to trace it with single step.
I will now try to step back to Version 4.xx and make my one RS232 receive buffer as it was before, will see.
Thanks for Your fast answer
best regards
Andreas |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Oct 01, 2013 8:35 am |
|
|
Quote: | the program starts hanging in a Loop which can not be traced by the Debugger |
I guess you mean can't be traced easily, or can't be traced at source level, or can't be traced in the
disassembly view. I'm rather sure that the failure can be observed in the debugger. |
|
|
Andreas
Joined: 25 Oct 2004 Posts: 136
|
|
Posted: Tue Oct 01, 2013 10:39 am |
|
|
Hi FvM
The interesting thing is, that the program don't go over a certain point, its always the same one and if i stop the Debugger i can see the pc looping at address 1FE52, 1fe54, 1fe56, 1fe52,......
In the program memory window I can see that at this address it shows 'RRRR' whatever that means !
I would be happy If you can show me how to find the position for this in the source.
If you like we can make a team viewer session, because I was not able to make a short program with the same problem.
Many Thanks and best regards
Andreas |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Tue Oct 01, 2013 12:19 pm |
|
|
If you're using MPLAB you can dump out the listing, it'll have the addresses and code( in assembler) with C next to it(or above....)
hth
jay |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Tue Oct 01, 2013 12:57 pm |
|
|
I haven't installed v5 yet, but with v3 & 4, you can view the C/assembly listing file. I assume v5 has this option as well. Might shed some light on the issue. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Tue Oct 01, 2013 2:38 pm |
|
|
Be aware that the new buffer functions are dangerous....
There is no buffer overflow testing. If you try to print more than the buffer can hold, or receive more data than the buffer can hold without processing, it goes completely erratic. They don't just lose characters, but transmits/receives garbage, and behaviour is erratic.
It may well be that this is what is causing your problem. I tried the new functions, and went back to standard sisr/stisr handling.
They are classic examples of the CCS 'good idea, poorly implemented'.
Best Wishes |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1345
|
|
Posted: Tue Oct 01, 2013 4:35 pm |
|
|
Actually, from what I could tell going through the ASM for my pic24's, they are designed weirdly, but you can figure out what they are going to do.
Incoming data is put on a ring buffer that doesn't check against next_out, so as soon as you fill your buffer, the buffer is empty (next_in == next_out). The next character becomes your first character again.
It basically fills normally until full and then resets. So if your buffer is 10 characters long, it will be "empty" when you receive the 10th character.
I still wouldn't use them as is. Losing the entire buffer once it is full is too wonky for me. They went for a quick and dirty solution, but not a very polished one. |
|
|
Andreas
Joined: 25 Oct 2004 Posts: 136
|
|
Posted: Tue Oct 01, 2013 11:19 pm |
|
|
Hi Guys
Thank you so much for your attention, I am running really crazy now.
I stepped back to 4.1xx, same problem.
Now I stopped the debugger and I can see that it runs in strange Memory area.
As I can not make a printscreen I will copy myself the area:
Program Memory
Line Address Opcode
65322 1FE52 RRRR
65324 1FE52 RRRR
65326 1FE52 RRRR
When I single step it runs forever in this Loop !
Can somebody tell me what means "RRRR" and what Memory area is that ?
Your help is gratefully appreciated.
best regards
Andreas |
|
|
alan
Joined: 12 Nov 2012 Posts: 357 Location: South Africa
|
|
Posted: Tue Oct 01, 2013 11:25 pm |
|
|
If you use CCS as debugger be careful about how they represent the assembly. Caught me and now I normally double check in MPLAB when I see some "strange" code.
Regards |
|
|
Andreas
Joined: 25 Oct 2004 Posts: 136
|
|
Posted: Tue Oct 01, 2013 11:26 pm |
|
|
Hello Alan
I am using MPLAB as IDE and CCS as Compiler only !
best regards
Andreas |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Oct 02, 2013 12:12 am |
|
|
Quote: | As I can not make a printscreen I will copy myself the area:
Program Memory
Line Address Opcode
65322 1FE52 RRRR
65324 1FE54 RRRR
65326 1FE56 RRRR
When I single step it runs forever in this Loop !
Can somebody tell me what means "RRRR" and what Memory area is that ? |
1. MPLAB can copy all windows to file.
2. I corrected the address typo according to your previous post
3. You didn't mention the involved processor, so we can't know if it's valid program memory space.
4. I'm not presently sure about the "RRRR" display. I mean to remember it as reseved area, which might be memory space occupied by the debug monitor. In any case, I would try to find out how the program execution gets there. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Wed Oct 02, 2013 12:22 am |
|
|
jeremiah wrote: | Actually, from what I could tell going through the ASM for my pic24's, they are designed weirdly, but you can figure out what they are going to do.
Incoming data is put on a ring buffer that doesn't check against next_out, so as soon as you fill your buffer, the buffer is empty (next_in == next_out). The next character becomes your first character again.
It basically fills normally until full and then resets. So if your buffer is 10 characters long, it will be "empty" when you receive the 10th character.
I still wouldn't use them as is. Losing the entire buffer once it is full is too wonky for me. They went for a quick and dirty solution, but not a very polished one. |
If the buffer is under 256bytes, then this may well be the only problem.
My 'expectation' would have been to throw one character, and set a flag in RS232_ERRORS.
However on the PIC18 at least, they don't protect 16bit values when interrupts occur. I found with a buffer over 256 characters, it was incorrectly handling 16bit addresses to the buffer, sometimes updating half, interrupting, and then updating the other half. Result a completely incorrect address outside the buffer was used.... Garbage, and on a receive, overwriting sections of memory.
I happened to try to use it for an application that receives a 'burst' transmission, which is then decoded over a couple of seconds. The buffer was large enough for the burst, but the result was corruption of areas of memory.
My own standard code didn't have this problem.
Unfortunately, the current solution is very poor.
Best Wishes |
|
|
Andreas
Joined: 25 Oct 2004 Posts: 136
|
|
Posted: Wed Oct 02, 2013 12:37 am |
|
|
Hello FvM |
|
|
|