RESTART_TRAP_CONFLICT

[E_Blue]

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]

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:

[Ttelmah]

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]

@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

[Ttelmah]

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]

I have this on the .lst file.

[Ttelmah]

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

This is almost certainly the problem.

[Ttelmah]

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]

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]

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]

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]

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

[Ttelmah]

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

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

[temtronic]

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]

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