PCD putc() help

[Swys]

Hi all,

I want to start writing a bootloader for myself so that I will be able to program my PIC over RS485, but I can't get past this simple problem. When I call putc('H'), the PIC doesn't send the character. But, when I call putc('H') twice, it actually sends the character...twice...

I thought that the program doesn't reach the putc command, but the LED connected to AUX_CS actually gets toggled.

Any help with this problem will be appreciated a lot.

I am using version 4.107 of the PCD compiler, with a PIC24HJ64GP504.

Below is my code:

[Gary Smithson]

The way you have main() written, the PIC is going to sleep before the character is shifted out the shift register. Remember that CCS places a sleep instruction just after main() and if you allow it to end, it will hit the sleep.

Try this:

[Swys]

Thanks for the answer Gary. I did exactly as you suggested, but it unfortunately did not work. It makes sense what you say about the sleep after main(), but why does the command after the putc('c') (toggling the LED) work? This is quite strange...

It now seems that if I use putc('c') an odd amount of times, it only executes an even amount of times. For example:

[Gary Smithson]

CCS probably has a bug. If possible I would first try the test as RS232 instead of RS485. In other words remove the enable parameter from #use rs232.

If the PC really does have an RS485 connection you can still remove the enable parameter and just drive the enable signal static active for the duration of the test.

I now remember from years past that a common mistake is to deassert the enable pin before the last character is shifted out the UART. If that happens the character will not be driven on the bus. That may very well be what is happening here depending on how CCS is managing the enable pin.

If that doesn't work I would remove the #org statements and let the program compile in a more natural state.

Hope that helps.

[PCM programmer]

There is a hidden Sleep instruction at the end of main(). It's placed there
by CCS. Any RS232 (that uses the hardware UART) that is "in progress"
will be shut down when it hits that Sleep instruction. Prevent this by
putting a while(1); statement at the end of main(). Example:

[Swys]

Thanks for your suggestions guys. Just before I came to check on the forum again, I tried writing to the UTXREG directly. At first this didn't work, when I thought (as Gary said) that maybe the enable pin doesn't stay high long enough for the byte to get pushed through the MAX3485. And sure enough that was the problem. So, I will be writing my own putc() function for this, toggling the enable pin myself...

Thanks a lot for your help!

[Jakesvanzyl]

I'm struggling with exactly the same problem. The problem can be fixed in 1 of 2 ways.

1 - Send the last byte twice for example

[FvM]

I'm not yet sure about the nature of the originally reported problem. With the #use rs232 enable option, the send routine is waiting for UxSTA.TRMT to go high before deasserting the enable output. This should be normally sufficient for regular RS485 direction control. It shouldn't be affected by the implicite sleep() at main end.

To understand, what's actually happening, one should inspect the TxD and Enable output lines with an oscilloscope.

I'm using the PIC24 hardware simplex control option instead of the CCS enable feature, because the delay involved with enable is inacceptable for an interrupt driven buffered send routine. The hardware simplex feature apparently works without any problems, but it isn't supported by the PCD built-in functions, it has to be enabled in special function registers. And it needs an additional inverter, because it's active low.

[Jakesvanzyl]

Thanks for the reply

I have monitored the enable line on the RS485 and it definitely goes low before all the data is out. What is strange about this problem is that it only happens when you have an uneven amount of bytes that you are sending. For example.

putc('c'); - will send no bytes

and
putc('c');
putc('c'); - will send "cc"

and
putc('c');
putc('d');
putc('e'); - will send "cd"

I have tried to manage the enable line in various ways manually. For example I have tried to use the #INT_TBE to pull the enable line down when the TX buffer is empty what is interesting about this is the fact that you have exactly the same problem as before the interrupt happens before all the byte are out which makes me think this might be a Microchip problem and not necessarily a CCS problem.

The implicite sleep() definitely has no effect since my controller does some serious communication work and it is in a constant do while loop.

[FvM]

I checked the PCD code with V4.107 and V4.112 and it's apparently evaluating the TRMT bit correctly. So I agree, that it's most likely a PIC24 silicon bug, respectively the operation of TRMT is different from what's said in in the family reference manual. Interestingly, there's apparently no problem when using the UART hardware simplex control option.

It's just a guess, but it may be the case, that TRMT can not be tested in the next instruction after loading the transmit buffer, one could try a short (a few instruction cycles) delay.

The issue may be also device dependant. What's your exact chip and hardware revision?

[Jakesvanzyl]

My device is a PIC24FJ48GA002 but we have seen the problem on a PIC24HJ64GP504 as well. I'm not sure how to check the hardware revision of the PIC but here is the full code of the PIC as displayed on the device.

PIC24FJ48GA002
-I/SO
101896M

I have tried a delay after the last character is loaded in the TX buffer the problem is the delay required is not "short" anything below 1ms does not work.

[FvM]

I could reproduce your even/odd number of characters observation. But I also found, that a delay before
checking TRMT actually matters.

The original PCD putc() code is equivalent to the below C-code. It shows the same behaviour as described above.

[Jakesvanzyl]

Thanks FvM

This has been a great help!

[FvM]

CCS has said, that the problem has been fixed and the next compiler release will contain the correction.