Strange problem with RS232, SPI and booting linux

[theteaman]

Hi

I have a PC that connects over RS232 to a PIC. This PIC connects to another PIC with SPI.

Now, what happens seems really strange. I switch on the PC and PICs through a shared power supply, the PC boots linux, the PICs just wait for a 'request' from the PC RS232 (a single byte). Once linux has booted, I run my program and... the SPI comms between the two PICs doesn't work.

So, I switch everything off, disconnect the rs232 cable, and then reboot the system. I let linux completely boot. Once linux has booted I plug the rs232 cable back in, run the linux program and... everything works straight away!

Something is happening on either the TX, RX or GND lines of the rs232 between the PC and the PIC during boot that is stopping the PICs from doing what they are supposed to. TX and RX are going through a MAX232 by the way.

I'm positive it's not a code thing because no transmission would occur until the linux program is started.

So I'm wondering if anyone has any ideas about this? The thing to note is that the system works when i disconnect the rs232 cable during booting linux. Otherwise, it doesn't and I have to take the PIC out of its socket for a moment, and put it back in, effectively resetting it and then it works. I'm stumped.. :/

Any help appreciated.
Thanks!

ps. here are my fuses:

[PCM programmer]

Can you prove that the Linux PC doesn't send anything to the PIC board ?

Do you have ERRORS in the #use rs232 statement ? If not, add it.

[theteaman]

[andyfraser]

I would put a scope on the TX line from the PC to see if during boot Linux sends data. It may be that Linux looks for a modem on the port by sending an AT command which might mess up your PIC code ?

Andy
www.sharpcontrols.net :: Free custom controls for .NET

[theteaman]

[SherpaDoug]

Could the PICs be getting power from the serial port, through the protection diodes on the PIC die, then to the VCC bus, before they get power from their own power supply. That might cause bad timing of the /RESET signal relative the the VCC seen by the PIC.

I had a product once that would go to sleep and shut off its own VCC, but could never wake up because the serial connection kept the VCC from going down properly and the PIC only went into some half-sleep mode.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Guest]

I have also seen issues where upon the PC initializing a serial port (especially a USB one) a bad character(s) gets sent - this can hang the first command that the PIC was waiting for. A simple solution is to have the PIC's wait for the entire boot cycle before actually setting the USART to receive.

This is not a problem because the PIC's can't do anything until the PC boots fully anyway.

You can hook a debug serial port on an unused pin and monitor any serial input into your PIC by spitting it out the debug port - to another PC - just to see what is going on during the boot.

Windows PC's sent AT commands on USB serial ports looking for Modems, which is annoying to the Nth degree.

HTH - Steve H.

[theteaman]

Thanks for the help guys. Turns out the problem WAS down to Linux sending bytes during the boot sequence. What I've done now is just make sure the pics don't start until they receive an "ID" which is working fine!
Placing a delay in the PIC as guest said was another solution however the problem with this method is that as I continually increase the speed of the Linux boot over time, the pics would need to be reprogrammed with shorter delays each time otherwise they would be waiting too long. Anyway, problem solved - thanks everyone!!

[Guest]

Yup - been there, done that! Glad you fixed the problem and confirmed the fix here on the board. That helps everyone in the future....

I have had the same issue with USB to serial adapters on the PC - some adapters when plugged in will emit junk when they enumerate that can hang my receive routines - a delay fixes that too.

Steve H.