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

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

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

Does anyone know what effect ICD has in Break Log mode?.
PostPosted: Tue Apr 07, 2020 1:19 am     Reply with quote

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!.... Sad

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



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

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 4:28 am     Reply with quote

re:
Quote:
Added this, and immediately the code
works correctly.... Remove it and it again stops working!..

hmmmmm...

What happens if you just put in some truly 'dummy' code, say have a new variable count to 10 , or just set/clear a register in the ISR ?

It almost sounds more like a 'timing' problem, maybe there's noise on the touch screen signal affecting the ISR or registers ? Or just that extra time inside the ISR allows 'something else' to settle down

I'm probably way off base here, but it does sound 'odd' that adding code makes it work.....
sounds like a 3 pot of coffee day and night to me ....sigh
Ttelmah



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 6:42 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 7:43 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 1:19 pm     Reply with quote

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



Joined: 20 Jul 2010
Posts: 1139

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 2:00 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Apr 07, 2020 11:43 pm     Reply with quote

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....
Sad
Ttelmah



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Wed Apr 08, 2020 11:49 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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