printf problems

[tmcneill]

I am getting verious errors in some printf lines.

Access Violation
DoSerIsr(int)
C:\nburn\MOD5213\system/irq_serial_init.cpp:127

I was also getting errors in fileio.sys
Around line 135. I changed the file some before posting so I can't remember the original location but this is the line
/*if ( ioctl_flags[fd] & IOCTL_TX_CHANGE_CRLF )

[tmcneill]

Here is another trap from fileio.sys
WinAddr2Line
write
C:\nburn\system_nn/fileio.c:158
IoExpands[fd].write( fd, buf + start, ( i - start ) );


-------------------Trap information-----------------------------
Exception Frame/A7 =20003D4C
Trap Vector =Address Error (3)
Format =01
Status register SR =2000
Fault Status =04
Faulted PC =FFC0B352

-------------------Register information-------------------------
A0=00000001 A1=FFC23A50 A2=200007A6 A3=000000A3
A4=200044C8 A5=000000A5 A6=20003D64 A7=20003D4C
D0=00000010 D1=00000000 D2=00000020 D3=20003E38
D4=000000D4 D5=000000D5 D6=000000D6 D7=000000D7
SR=2000 PC=FFC0B352
-------------------RTOS information-----------------------------
The OSTCBCur current task control block = 200034E8
This looks like a valid TCB
The current running task is: User,#0A
-------------------Task information-----------------------------
Task | State |Wait| Call Stack
Idle,#3F|Ready | |FFC0A1C4,FFC0C284,0
User,#0A|Running | |FFC0B352,0

[tmcneill]

I am trying to track down the problem with the fileio.c. I make the write routine loop through IRQ_whritechar to send the data and when I do that there is no problem at all. So I started to track fd and port = ( DWORD ) IoExpands[fd].extra;

Something appears to be corrupting the port. At the beginning of the routing that I see the problem in I had a printf("\r\n#"); I wanted the pound side to act like a beginning of the line like in unix shell. If I take the # out of the line the IoExpands[fd].extra; doesn't change but when I put the # in the value changes from 0 to 1.

My code is a simple loop. I do not have any threads other than the main function.

Anyone have any ideas?

[rnixon]

The first thing to check is to make sure you do not have a stack overflow problem. Are you declaring any large arrays or other auto variables? The printf function links in all the floating point stuff and consumes a lot of memory, so if you are low on stack space calling it could produce this problem. If you don't need floating point, you can use iprintf instead, which is smaller. How much memory are you allocating?

[tmcneill]

I do have some arrays I am doing memsets on but they are all static with the size defined in the include file. This code worked wthout problems on the nndk from two years back. I just recently renewed and am now having these problems.

I do not have any problems when I hard code fileio.c to use the serial irq write function without using any of the IOexpands varaible.



Used 17312 bytes of 31488 availible ram (54.98%)

[tmcneill]

I think I got it all working but I had to go around the problem. I had to turn on stdio and stderr. I use sprintf instead of printf and then use IRQ Write String to send that string. It has not crashed yet. I think the problem is with the stdio routing to a serial port.

Thomas

[lgitlitz]

I think you need to re assign the stdio file descriptors. At boot stdio is assigned to the file descriptor of the debug serial port. This file descriptor uses a low-resource polling UART driver which is different then the interrupt driver used when you call openserial. If you then call open serial on this port the file descriptor returned is for the interrupt based UART but stdio is still linked to the polling based driver. Now when you call write or read functions for the interrupt FD they will conflict with stdio calls that use a polling based FD on the same UART.

This is currently the proper way to open a serial port that uses stdio:
SerialClose( 0 );
int fddebug = SimpleOpenSerial( 0, 115200 );
ReplaceStdio( 0, fddebug ); // stdin
ReplaceStdio( 1, fddebug ); // stdout
ReplaceStdio( 2, fddebug ); // stderr

There has recently been a major rewrite of the serial driver that will be in the next release. A fix to this issue has been added. Now if openserial is called on the debug UART and stdio is assigned to the debug FD, stdio will automatically switch to the interrupt based FD.

-Larry

[tmcneill]

I tried it using that as well. Everything would work fine and then bam corruption but now that I go directly to the serial port I have no problems.

Thanks