Does anyone know what effect ICD has in Break Log mode?.

[Ttelmah]

DsPIC33FJ128GP802. Running at 60MHz.

Being used to handle a touch screen and display controller.

Has multiple nested interrupts.
Highest priority INT_TIMER3, INT_RDA, INT_TBE (level 5)
Then INT_EXT0 at level 4
INT_TIMER4 at level 3
and INT_IC1 at level 1

INT_EXT0 handles the actual 'touch' event from the screen.
INT_TBE, and INT_TIMER4 are disabled at this point.
The handlers for INT_TIMER3, and INT_RDA, are 'quick' (don't take
more than a very few uSec to handle), and have long gaps between them.
The physical screen transfers are done using DMA to the SPI.

INT_EXT0 goes low when there is a touch event from the screen.
Having an issue at one point, where the event was not doing what I
expected. I therefore decided to add a 'break log' in the handler for this
one event, that would just record the actual value decoded from the
controller in this event. Would prove that the event was triggering
correctly, and being decoded. Added this, and immediately the code
works correctly.... Remove it and it again stops working!....

So the question is whether anyone 'knows' what effect the ICD
debugging actually has on the running code when a value is
logged in this manner?. Using ICD-U64 or U80 (same with both).
Value being logged is just a UINT8_t.
I'm 'guessing' that there is perhaps a call to the ICD code kernel.
that then copies the logged value, so perhaps a few uSec of delay.
However tried just inserting delay_us(5) at the same point in the code
and it still doesn't work. Also tried just copying the value into another
temporary variable. Again doesn't work.

So does anybody have any idea what the debugger actually 'does'
when you ask it to log a variable this way?.

[temtronic]

re:

[Ttelmah]

That's exactly what I thought, which is why I tried the delay.
Given the processor is running at 30MIPS. I can't see that it can take
very long to handle this.
Will try a little 'more complex' code and see what happens.
The silly thing is there is no reason at this point for any timing at
all to be involved. I just load the byte into a circular buffer and exit
the interrupt. The interrupt trigger source is cleared by the act of
reading the byte, and on two other routes there is no problem with an
immediate exit.

[Ttelmah]

It's something to do with memory access.
If I copy the value into another unused variable, it all merrily starts working.
It's odd, since all the registers are restored by the return. Also the
status register should be restored as well (otherwise I'd suspect this
is being changed).
Wondering if the extra variable is changing a memory alignment....

Investigating!.

[Ttelmah]

Yes, it changes the data alignment when enabled.
Interesting side effect....

[jeremiah]

Something to consider. We are running some versions in the 5.080's range and have run into a compiler bug where some peripherals are generating code that clobbers memory sometimes. In our case it is a SPI peripheral which has an internal 8bit variable it allocates but uses 16bit clears on it in some places.

We reported it to CCS and they plan on fixing it, but we don't know if they have fixed it yet or not as we haven't gotten the latest versions installed yet (we also don't know if any versions earlier than the 5.080's have the same problem or not).

You might consider looking at any related peripherals and see if CCS allocates any odd sized variables internally in the symbol table, then check the LST to see if all writes to those locations are 8 bit.

The other thing is make sure not to mark interrupts on different priority levels as "FAST" as it will use the shadow register stack and there is only one, so interrupts on different levels will clobber the shadow register stack.

[Ttelmah]

Thanks.
Yes this is where I'm at currently. I've had to replace the SPI library
to use DMA. However there are several library function variables and
variables from my code, that seem potentially may be resulting in a
corruption problem. I'm strongly suspicious, that the compiler handling
of nested interrupts in particular may not actually be quite correct,
especially as code gets larger....

[Ttelmah]

OK. Have finally worked out what it changes.
The act of enabling the break log, results in a DISI instruction being
added. This changes how the buffer updates. Without this one of
the higher priority interrupts can trigger during the write to the buffer.
Currently tweaking the write so that this can't happen.