I2C dependency on UART transmission (s08sg32)

[Witya]

Hello everyone,

I have a quite strange dilemma, let me try to explain.

The app during initialization of I2C protocol, e.g. writing or reading I2C block, hangs for ~10 sec, then continues... since there should be quite a lot of this read-write routines for initialization and needed data transmission, instead of 3 secs we have a lot of time... once I waited 30 mins, when went to lunch.

debugging is done by the UART terminal, using DockLight (don't ask why)

so for debugging I was sending characters over the UART, which trigger Tx line in uC, to see which functions hang the app... then after sending characters, there was no more hanging and app continues to the next functions. so sending a character before the read or write I2C block routine, eliminates hanging and app works as it should...

I wonder why this happened? and btw delays could not replace sending characters, cause I thought sendchar funct. created a delay, that was needed for initialization. I tried 50us, 100us, 150us, 200us and bigger values like one to hundreds ms.

any ideas are welcome

[bigmac]

Hello,

My best guess is that you are continuously re-entering one of the ISRs because the associated interrupt flag is not being cleared.  This would leave little time available for execution of the main loop code.  Athough I am a little surprised that COP timeout does not occur - unless you have the COP timer disabled, or are clearing the COP timer within the ISR (a big no-no).

If you happen to be using interrupts to send SCI characters, using the TDRE flag, this interrupt source must be disabled once the character(s) have been sent.  Maybe you have prematurely enabled this interrupt source during intialisation, prior to characters being available for sending.  But this is a wild guess.

Are you not using the USB Multilink Interface for debugging the code?

Regards,

Mac

[Witya]

hey mac,

actually you are right TDRE flag is used for sending SCI char. 

that is an interesting thought, I have to look if it is enabled prematurely.

since this is not my code, I will also ask the developer about the COP timer.

my guess is when sendchar is occurred, it only enables the interrupt, but not disables it. here is piece of code:

void SendChar(T_UINT8 ui8_char) {

 

  SCIC2 |= 0x08;    // enable Tx

  while(!SCIS1_TDRE){ }

  SCID = (T_UINT8) ui8_char;   // 2nd half of TDRE clear procedure

} //end SendChar

with usb multi link, everything shows fine, just when the app is running there is these ~10s lags, mentioned in 1st post.

[bigmac]

Hello,

The SendChar() function that you have shown actually polls the TDRE flag before sending the character, so there is no need for interrupt use.  I notice that the function also sets the TE bit.  If this bit was previously clear, the result will be that an idle character is sent first, then followed by the required character, thus extending the transmission period. 

Usually the TE bit would be set during SCI initialisation, and would remain so.

Regards,

Mac