CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

RESTART_TRAP_CONFLICT
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

RESTART_TRAP_CONFLICT
PostPosted: Thu Jan 14, 2021 1:59 pm     Reply with quote

I'm getting the device constantly halted by the debugger (about every 12 seconds); so I checked if there's an internal reset like WDT reset and I get that the cause is a RESTART_TRAP_CONFLICT.

So I made a little research here and found how to know the address that is falling in to the trap.
I found that is the address 0x1462 which is in the CCS @const section.
The place where the compiler puts the strings declared in the code.
So, can be this a bug in CCS compiler code?

CCS V5.091
MPLAB X IDE 5.15
PIC24FJ1024GB606
_________________
Electric Blue
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Thu Jan 14, 2021 8:29 pm     Reply with quote

Not sure about this compiler version (I use 5.026) and I don't use the debugger. I am not familiar with the RESTART_TRAP_CONFLICT but I do use the PIC24 devices.

Posting code will help. Can you reduce your code to the bare minimum and still re-create the problem?

As for the error, is this an address trap? Can you add / do you have the #INT_ADDRERR interrupts and the #INT_STACKERR enabled?

If you call RestartCause = restart_cause();, what do you get?

Let's say it is an address trap, I use the following code which was provided I believe by either Ttelmah or PCM Programmer (don't remember) and was very useful in finding address errors:

Code:


#INT_ADDRERR
void ADDRERR_isr(void)
{
   unsigned long trapaddr;

   #asm
   mov w15, w0
   sub #38, w0
   mov [w0++], w1
   mov w1, trapaddr
   mov [w0], w1
   and #0x7f, w1
   mov w1, trapaddr+2
   #endasm

   fprintf( MONITOR_SERIAL, "\n\rTRAP ADDRESS: 0x%08X", trapaddr );

}


The address captured is the address immediately following the true address location that caused the crash. I've had this address trap interrupt occur when, let's say, searching in a string until NULL or last character but in my case, the data was longer than the string therefore no NULL was found therefore the while loop caused the crash.

Ben
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 3:56 am     Reply with quote

A RESTART_TRAP_CONFLICT, can be caused by the stack overflowing.
What is your stack size set to?. Printf, can use quite a lot of stack. So it
might be simply that the access to a string 'inside' something like a
printf, is resulting in a stack overflow.
Generally on PIC24/33 code, the stack always needs to be significantly
expanded beyond the compiler default.

#build (stack=0x400)

Gives 1KB of stack.
Be very careful. The stack size here is in 'bytes', but the stack size reported
in the .lst file is in 16bit words. So a program that says:

Stack used: 464 locations (14 in main + 450 for interrupts)

Needs a minimum of 928 bytes of stack (so 1KB).
The #build I show is for the program reporting this stack use.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 5:53 am     Reply with quote

@benoitstjean The restart cause is 15, that's how I found this kind of reset that I wasn't aware before.
This is my first PIC24F program.
So I searched here and found that ASM code to get the trap address and get the 1462.

@Ttelmah What? I didn't know about that.
The same code is working in a PIC18F which have 31 stack levels. How is that now it needs 1KB?
Where is located this info "Stack used: 464 locations (14 in main + 450 for interrupts) "?
In the build output can't find that and in the left panel there's only info about Flash size/used, RAM size/used and breakpoints available/used.

This is what I have around address 1462
Code:
01426  EF2054     CLR TBLPAG
001428  214323     MOV #0x1432, W3
00142A  418000     ADD W3, W0, W0
00142C  BA4010     TBLRDL.B [W0], W0
00142E  EF6001     CLR.B 0x1
001430  060000     RETURN
001432  00493B     NOP
001434  003D44     NOP
001436  007325     NOP
001438  00233B     NOP
00143A  003425     NOP
00143C  00584C     NOP
00143E  002A3B     NOP
001440  000000     NOP
001442  EF2054     CLR TBLPAG
001444  2144E3     MOV #0x144E, W3
001446  418000     ADD W3, W0, W0
001448  BA4010     TBLRDL.B [W0], W0
00144A  EF6001     CLR.B 0x1
00144C  060000     RETURN
00144E  005024     NOP
001450  00544D     NOP
001452  00324B     NOP
001454  003135     NOP
001456  00312C     NOP
001458  003239     NOP
00145A  003030     NOP
00145C  00322A     NOP
00145E  000D32     NOP
001460  00000A     NOP
001462  EF2054     CLR TBLPAG
001464  200243     MOV #0x24, W3
001466  500183     SUB W0, W3, W3
001468  310005     BRA C, 0x1474
00146A  2147E3     MOV #0x147E, W3
00146C  418000     ADD W3, W0, W0
00146E  BA4010     TBLRDL.B [W0], W0
001470  EF6001     CLR.B 0x1
001472  060000     RETURN
001474  2147E0     MOV #0x147E, W0
001476  418183     ADD W3, W3, W3
001478  418180     ADD W3, W0, W3
00147A  BA8013     TBLRDH [W3], W0
00147C  060000     RETURN
00147E  2C5024     MOV #0xC502, W4
001480  30544D     BRA OV, 0xBD1C
001482  2C334B     MOV #0xC334, W11
001484  303431     BRA OV, 0x7CE8
001486  2C302C     MOV #0xC302, W12
001488  30312C     BRA OV, 0x76E2
00148A  2C302C     MOV #0xC302, W12
00148C  30302C     BRA OV, 0x74E6
00148E  2C312C     MOV #0xC312, W12
001490  30302C     BRA OV, 0x74EA
001492  2A302C     MOV #0xA302, W12
001494  32302C     BRA Z, 0x74EE
001496  38302C     BRA NOV, 0x74F0
001498  0D302C     BRA OB, 0x74F2

_________________
Electric Blue
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 7:02 am     Reply with quote

The stack on the PIC24, is totally different.

On the PIC16/18, the stack can only hold return addresses. Nothing else.
So if you have routines that run (say) ten deep, ten stack levels are all
that is needed. On the PIC24/33, the stack is used to actually hold values
as well as return addresses. So a single call to a routine may on it's own easily
use forty stack levels!... So where the PIC18 needed just ten stack levels,
the same routine on a PIC24, can easily need 400 levels!...

The stack defaults to 128 levels. This is not enough to even have a single
routine calling a printf. (eeek).

Look at the top of the listing file. With two caveats, this figure will tell
you what is needed.
The caveats are that as already mentioned this is in 'stack levels', not in
bytes, and that it sometimes seems to need a tiny bit more than this says
(so don't run right tight to what this is saying you need).
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 9:43 am     Reply with quote

I have this on the .lst file.
Code:
 ROM used:   75346 bytes (11%)
                           Largest free fragment is 65536
               RAM used:   3396 (11%) at main() level
                           3802 (12%) worst case
               Stack used: 238 locations (174 in main + 64 for interrupts)
               Stack size: 320

So, should I must to increase the stack size?
_________________
Electric Blue
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 11:30 am     Reply with quote

Yes. You need a minimum of 476 bytes. So set it to 512.

This is almost certainly the problem.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 11:53 am     Reply with quote

As a comment, the reason you have to make the stack slightly larger
than their figure, is that the ICD uses a little stack space, hence a little
more is always needed if you are using an ICD.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 11:53 am     Reply with quote

Ok, so CCS does not automatically set the stack size as is needed.
Thanks.
What about the "Compile for use with ICD"? How affects the code?
Is just a NOP at address 0x0000?
_________________
Electric Blue
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 12:14 pm     Reply with quote

re: Ok, so CCS does not automatically set the stack size as is needed.

They probably set a 'default' size, but really 'as needed' could take a huge amount of time to compute. Just think of the number of potential paths a few 'if-then-else' tests in a row could have ? Kinda like playing chess, how many moves do you think ahead ??

Most 'powerPICs' have LOTS of RAM , so setting aside 1K ,2K even 4K for the stack isn't normally a big deal even if you force all variables to be 'global'.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 1:30 pm     Reply with quote

I made a mistake, the value of trapaddr=0x0040E000 not 0x1462

That's bigger than the FLASH size.
I'm lost.

My trap isr have a #36 instead #38 on the second ASM line.
Can be that?
_________________
Electric Blue
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Fri Jan 15, 2021 1:45 pm     Reply with quote

I just changed #36 by #38 and found the error, there's no isr for TX UART2.
I can believe it.
_________________
Electric Blue


Last edited by E_Blue on Sat Jan 16, 2021 5:08 pm; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Jan 16, 2021 3:03 am     Reply with quote

Very Happy

Repeat thirty times. Every enabled interrupt, must have a handler.....

Most of us here will have done something similar at some point.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 16, 2021 6:31 am     Reply with quote

too many late nights, too much coffee, BTDT

I've eliminated most 'sillies' by copying the source, save as nextversionxxx,only making a couple changes in code,recompile, test, do it all again. Yes, I have can have 30-40-50+ versions BUT it's easy to go back.
Yes, the HD is stuffed with a zillion files as every compile generates 6 or 7 files. That's not a big problem..SEEINg ; instead of : IS !

Jay
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Sat Jan 16, 2021 5:07 pm     Reply with quote

The problem was that the version 1.0 of the PCB used a GPRS modem that includes a GPS and the GPS module was configured trough the modem UART1 and the GPS data was available in a separate UART2; so no need to send anything trough UART2 and so no need for a TX2 ISR.

That integrated GPS has serious issues so in PCB V2.0 we decided to use a separate GPS that requires some commands; I added the proper routines to load TX2 buffer and forgot to add the ISR for UART2.
_________________
Electric Blue
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group