Debug verse Release strange behaviour PIC18F6622

[stolzie]

Hi All

I have a project that uses two RS232 interfaces. One uses the EUSART module and the other is software. While running in debug using an ICD2, the code works perfectly. But when I program the PIC for release, there's a weird timing issue that screws up the RS232 data.

I'm using a PIC18F6622. MPLAB IDE v8.50. And an ICD2.


Code for the hardware Interface:

void rs232PutA(BYTE output)
{
  
   INTCON_GIEH = 0;   // Putting this in didn't change the result

   while (!PIR3bits.TX2IF);

   TXREG2 = output;
  
   INTCON_GIEH = 1;
}

Code for the the software Interface:

 void rs232PutB(BYTE output)
{
   unsigned char bitCounter;
   int waitCount;
  
   // Disable Timer Interrupt
   INTCON_TMR0IE = 0;
   INTCON_GIEH = 0;  // Putting this in didn't change the result
  
   switch (AppConfig.PortB.RS232_Baud)
   {
       case 0 : waitCount = WAIT_PERIOD_2400; break;
       case 1 : waitCount = WAIT_PERIOD_4800; break;
       case 2 : waitCount = WAIT_PERIOD_9600; break;
       case 3 : waitCount = WAIT_PERIOD_19200; break;
       case 4 : waitCount = WAIT_PERIOD_38400; break;
       case 5 : waitCount = WAIT_PERIOD_57600; break;
       case 6 : waitCount = WAIT_PERIOD_115200; break;
   }

   // Send Start bit
   Tx_B = 0;   
   rs232Wait(waitCount);
  
   // Send data bits
   bitCounter = AppConfig.PortB.RS232_Bits;   
   do
   {
       if (output & 0x01)
           Tx_B = 1;
       else
           Tx_B = 0;
                 
       output >>= 1;
      
       rs232Wait(waitCount);

       bitCounter--;
      
   } while (bitCounter);
  

   // Send Stop bit
   Tx_B = 1;
   rs232Wait(waitCount * AppConfig.PortB.RS232_StopBits / 2);
  
   INTCON_TMR0IE = 1;
   INTCON_GIEH = 1;
  
}

void rs232Wait(int waitPeriod)
{

   do
   {
       Nop();
       waitPeriod--;
   } while (waitPeriod);
  
}

The results that I'm getting under release is if I send (say) an ASCII Char '1' (0x31), I recieve a mix of the '1' and '9' (0x39) and the occasional random character. If I send an 'A' (0x41), I get a mix of 'A', 'a' (0x61) and 'y' (0x79) and occasional randoms.

So it seems as if some voodoo gremlin is delaying the controller while its forming the RS232 waveform. And I'm getting (pretty much) the same result with both the EUSART and the software interface. And it works flawlessly in debug. I've even programmed the PIC using a PM3 with the same result.

Can anyone shed some light on what this might be.

Thanks in advance.

Stolzie

 

[Pommie]

As you state, it looks like a timing error but without a working example how are we supposed to even guess what the problem may be. Post a cut down version that exhibits the problem and we may be able to help. Also when you state "if I send (say) an ASCII Char '1' (0x31), I recieve a mix of the '1' and '9' (0x39)" - what is sending and what is receiving?

One thing to keep in mind, if the PK2 is selected as a debugger, MPLAB still puts the debug code in the chip even if the release version is selected. Select PK2 as a programmer to program the release version.

Mike.

 

[stolzie]

Hi Mike,

Thanks for the reply. The problem is with sending the data out from the PIC. E.g. I am sending out ASCII Char '1' (0x31) via the EUSART on pin RG1 and receiving the data through a USB to serial convertor and displaying the results. The same problem occurs when we have implemented a software USART. Works fine in Debug but as soon as programmed for release we get the shifted bits.

We have programmed the unit with an ICD2, ICD3 and a PM3 all via MPLAB and all devices are set as programmers. And all have the same results

SPBRGH2 = 0x04;
SPBRG2 = 0x10;

PIE3bits.RC2IE = 1;
TXSTA2 = 0b00100100;
RCSTA2 = 0b10010000;
BAUDCON2 = 0b00001000;

Thanks

Stolzie

 

[Pommie]

What can I say, the UARTS work flawlessly with or without debug and so it is something in the rest of your code. As you will not post it, make sure you initialize everything as the debugger may initialize something you're not aware of.

BTW, why are you using a software UART on a chip with two hardware ones?

Mike.

 

[stolzie]

Hi Mike,

Well I didn't want to post about 10 pages code that would waste peoples time so I thought I would post the most important parts with initialising the UARTS and the UART code itself.

As we are still unsure what is actually causing this problem we are going to start stripping out code and testing the UART at various stages to see if anything is being over written or messed with that we haven't be able to locate.

BTW, why are you using a software UART on a chip with two hardware ones?

We have already implemented the two hardware ones and needed another for additional communications.

Thanks again.

Stolzie