Serial data problem with upgrade 4.099 to 4.124

[temtronic]

In a previous post you've got what appears to be a 32bit math operation that will disable interrupts.....that takes a LOT of time and I can see the UART buffer being overrun unless coding that we haven't seen takes care of that situation.

[cassioriguela]

[Douglas Kennedy]

in your ISR you have
pRxInicio = (pRxInicio + 1) % ZIGBEE_BUFFER_RX_SIZE;

looks like modulo math to me.

[temtronic]

and if

.. ZIGBEE_BUFFER_RX_SIZE is NOT a nice binary number (8,16,32)

then the code for the % code gets real messy and TIME consuming !

[Douglas Kennedy]

>>> Warning 216 "main.c" Line 5396(0,1): Interrupts disabled during call to prevent re-entrancy: (@PUTCHAR_3_)
>>> Warning 216 "main.c" Line 5396(0,1): Interrupts disabled during call to prevent re-entrancy: (@DIVS3232A)

Looks like a clue ... the compiler using internal functions with putchar and with divs 232 maybe a software uart with calls both in main and in an ISR.
Both pins have to be hardware uart pins for the hardware uart to be active.
If you don't want to specify the pins use UART1..UART2 etc.

[cassioriguela]

Hello my friends,

It's working now. I was looking for instruction that was generating warnings, so I found a fprintf statement that i was using for debug. The warning disappeared when i commented this statement and It starts to work perfectly. I don't know the relationship with fprintf instruction and my ISR function. If some CCS guru, like PcmProgrammer or Ttelmah, could explain to me, I will be glad.

Thank you all !!!

[Ttelmah]

The hint has to be in the putchar_3 warning. Somewhere in an ISR (possibly not one you have posted), there must be another putc/printf, that is using the same port used for the debug.

Best Wishes

[cassioriguela]

Thanks for response, Ttelmah

You were right. I was using a fprintf instruction for debugging trap conflicts interrupts so it was causing the problem.

Thank you !!