RCM6760 initialization problem

I have designed a ‘remote telemetry unit’ using the RCM6760 as its brain. It has digital and analog inputs and outputs as well as four serial ports and an LCD display. I am having a terrible time getting my software to run on the RCM6760. I have stripped it down to try bare bones to find the problem.

For programming, I added a 10-pin programming port to my board like the older RCM3100’s have on them. I can use the old programming cables connected to my USB port to program this chip. That seems to work fine. However, I am having an issue at start-up. It seems that, depending on what I add to my code it will not come out of the setup mode (possibly). Currently I have a simple code to just drive line PA7 high every 1/2 second and low every other 1/2 second for a pulse period of 1 second.

I have noticed that on start-up (using an oscilloscope on line PA7), that this line will pulse high on it’s own every couple of seconds and then low for a little less than one second, over and over. And while that is going on the Serial Port A TX line also transmits (I have an LED driver tied to the port so I can visually see it). Using HyperAccess, I see it is a non-printing character [00]. It might do this for 30 seconds or a minute and then it goes away and line PA7 starts going high and low normally, as currently programmed. If I uncomment any other code or change anything, it usually breaks it completely and it never gets out of that cycle of pulsing the TX line of port A. Am I forgetting to do something on start up?

I want to use Port A for an RS232 serial port when my program is running. I have done this with an RS485 port before with the RCM4100 processor and it seems to be working fine.

Has anyone seen this type of start-up problem? I can’t go any farther with my code until I can get it to run immediately. The ‘pong.c’ program will run so my processor is OK. I just can’t figure out what is hanging it up on start - up so easily and don’t know how to show my code to anybody.

I have an InitBrd() subroutine that sets up all of the parallel ports and serial ports. I have written the 0x84 to SPCR to set it up in that routine like this…

// Configure Port A as Outputs
WrPortI(SPCR, &SPCRShadow, 0x84);
// PA0-PA2 = ADDRESS LINES A0-A2, PA3=RS485 DE, PA4=RS485 /RE, PA5=RS232-D RTS,
// PA6=RS232-A RTS, PA7=DIO /CS
WrPortI(PADR, &PADRShadow, 0x90); //startup values for chip select and address lines

However, it has to get to this point first!.

Oh, maybe a good clue… Even when the program start running that simple code to toggle that one line high and low, if I connect a serial port to port A (through a MAX3232 chip) and type anything in over Hyperaccess, it will revert back and start transmitting the [00] code to me again for a while.

If I leave that serial port alone and it does start toggling my bit, it seems to be stable (going by my oscilloscope.)

Something is buggy about this and I am having trouble figuring out if it is hardware or software. I tend toward software since it is not consistently starting the same way and I can break it easily by adding other code in my main program (which shouldn’t be affecting the initialization, but seems to be.)

Here are the pins on my programming 10-pin header:
1: RXA, 2:GND, 3:CLKA, 4:3.3vdc, 5:RST, 6:TXA, 7:no connection, 8:Status, 9 & 10: Smode

I have to get past this problem to get anything else working. Almost everything is run over SPI lines (except the serial ports) and it won’t let me initialize the rest of my hardware. I am using this particular line for my multiplexer chip select line. My other chip select lines are actually controlled by another multiplexer so I’m stuck until I can get this problem worked out.

95 percent of my hardware has been used before on another product with other RCM modules so I’m confident in my basic design and the code it takes to communicate with it.

Oh, I almost forgot, my compiler is Dynamic C 10.70

10/10/14 UPDATE: I am still working on it, but the problem seems to be in my board initialization routine where I set up the parallel and serial ports for the processor. I stripped down my program going by the Samples\STDIO_SERIAL.C program and redirected the stdio port to serial port A so I could watch it on Hyperaccess. I am printing out some lines of text perfectly at 57600 baud when only doing that. When I added in my InidBrd() routine which writes to the hardware ports using WrPortI() and call it, it breaks my program. I’ll go over it again and see what I need to do to fix it. Something isn’t being set up correctly and it gets stuck in that loop that is almost like a reset every 2 seconds.

I suggest that you run one of the RCM67xx samples to see if the same issues occurs there

Serial Port A is used to communicate from Dynamic C to the board. Is this behavior in standalone mode or in debug mode?

Also, you may want to check the BIOS to see what is going on with Parallel Port A in there. Upon reset, the processor manual will tell you what the registers are set to by default. This would all happen before your code is reached.

Thanks for the help… I have made a lot of progress this morning. The problem is in my attempt at initializing serial ports E and F. I have those lines of code commented out right now. With that out of the picture, the program is running and I have the SPI bus running. I have tested 24 digital inputs, and 17 digital outputs… That means I am correctly communicating to at least four of my multiplexers. Codes on the scope look good for those chips on the SPI bus. Serial Port A is working too. Hopefully I won’t have too much trouble getting ports E and F functional. I have not tried them today since I wanted to get some of the other things checked out first. I’m doing a lot with this processor and still have to read my temperature chip, write to my LCD display, get the other serial ports tested, communicate with my analog input and output chips and the two external flash memory chips, but I’m glad I’ve made progress this morning. Thanks again for the help. Starting with some of the Sample programs really helped me narrow down the problem.