Other Parts Discussed in Thread: TMS570LC4357,
On a previous post here, I was trying to understand why my GIO interrupts were working intermittently. After some experimentation by myself, I arrived at two pieces of code, one that always worked and one that would never work (or so I thought):
This would never call the interrupt:
/* This would never increment DEBUG_counter */
int main(void)
{
/* USER CODE BEGIN (3) */
_enable_IRQ();
gioInit();
gioEnableNotification(gioPORTB, 2); //Pin 2 is the one being tested
while(1){
asm(" nop");
asm(" nop");
asm(" nop");
}
/* USER CODE END */
return 0;
}
uint32 DEBUG_counter = 0;
void gioHighLevelInterrupt(void)
{
uint32 offset = gioREG->OFF1;
/* USER CODE BEGIN (14) */
DEBUG_counter++;
}
This will call it every single time:
/* This would always increment DEBUG_counter */
int main(void)
{
/* USER CODE BEGIN (3) */
_enable_IRQ();
gioInit();
gioEnableNotification(gioPORTB, 2); //Pin 2 is the one being tested
while(1){
DEBUG_counter[5] = pmmREG->GLOBALSTAT;
}
/* USER CODE END */
return 0;
}
uint32 DEBUG_counter = 0;
void gioHighLevelInterrupt(void)
{
uint32 offset = gioREG->OFF1;
/* USER CODE BEGIN (14) */
DEBUG_counter++;
}
After a lot of digging, document reading and triangulation, I found that the root cause of the interrupt failure was the debugger: if I tried to read any value of the register GIOB, probably due to emulation mode, the interrupt would stop working for that debugging session. Just having he register structure tree open in CCS while refreshing is be enough to cause this, but ONLY with the FIRST code above. The second one seems to be immune to this issue.
Now I know what causes this and how to sidestep the issue, but to prevent this from happening again through other means, I have a few questions on this behavior:
1. If the interrupt is stopped while debugging (emulation mode, I suppose), why is the interrupt flag clear? Shouldn't it be kept on, as reading OFFSET does not clear the flag or OFFSET?
2. Why the code that reads another, unrelated, register prevents this from happening? How is emulation mode affected by this code? It is a bit disturbing to have these unexpected dynamics between code and unrelated peripheral state, even if during debugging.
3. Once the emulation mode is triggered in the first code, is there any way to manually return the peripheral to normal mode without resetting the CPU?
4. Is there any documentation on other effects of the debugger on TI's TMS570 controllers? How can I rest assured that my tests are not getting in my way of observing the code behavior? I found sparse notes on other peripheral's sections of the TRM, but it is all very superficial as in the case of GIO.
5. Is there any programmatic way of detecting this?
