Debug PrintF Serial Port ReDirection

Rabbit
1

I am having problem with the redirection of the Debug PrintF statements to the Serial Port.

I have setup the Serial Port with:

#define STDIO_DEBUG_SERIAL SDDR    //Defines what port
#define STDIO_DEBUG_BAUD 9600      //Defines Baud Rate
#define STDIO_DEBUG_ADDCR          //Adds a CR to the linefeed
#define STDIO_DEBUG_FORCEDSERIAL   //Enables Serial Output even with programming cable attached

Everything works fine with the programming cable attached. Sometimes I reset the Rabbit RCM3000 and it still works. BUT for the MOST part, the unit outputs garbage. If I leave it unplugged for 10 minutes and try again, it outputs garbage (Wrong baud rate???) and will never work again. plug back in the programming cable and bingo, its all good till its off ofr a while.

I use Dynamic C 9.61 and a RCM3000 or RCM3010.

The data is fed to a serial printer for archival information.

I am trying to figure out if the printf has anything to do with Debug mode? Whenthe rabbit is running, its in run mode? I do not declare in my program to be in debug mode, but the printf statements come out in STDIO window just fine. Im puzzled.

2

Not to bump my own thread, but I have some more info.

I removed my printf commands from my software today.

I built a function that takes a character string and writes it directly to Serial Port C.

Heres the thing, I use serCputs and it WORKS FINE when connected to the program cable. Once I disconnect the cable and reboot the rabbit, the serial baud rate appears to fowl up and it prints garbage.

I do not understand where it is getting changed. I properly call serCopen(9600) after brdinit andit should be OK.

ANY IDEAS on why the serial output baudrate is not working in “run mode” ??!!

my buffers are large (guess making the inbuffer large is a waste ATM)

#define CINBUFSIZE 2047
#define COUTBUFSIZE 2047

3

So after finding a note in Dynamic C 6.0 about problems with freq_divider, I think I have found the problem.

When I restart the Rabbit after a successful download of the software, the freq_divider ends up being 0 (yes, ZERO) on restart.

If I reset it to 48 which is what my RCM3010 normally is, the problem is gone.

WHY doesnt the rabbit boot up and get the proper freq_divider?

I have a Lithium Battery on the RCM3010 which keeps > 3Vdc (3.1 approx) on the Bat_Ext line at all times.

I dont want to hardcode freq_divider = 48 into my software espeially if I plan to move onto the RCM3900 and use Mass Storage soon. It may be different, the whole reason it is stored on the Rabbit itself.

Any ideas why I have this problem?