NetBurner Community Forum

I apologize if this is in a forum somewhere - I did a search with no results.

In UserMain, using the following code.

InitializeStack();
if (EthernetIP == 0) GetDHCPAddress();
OSChangePrio(MAIN_PRIO);
EnableAutoUpdate();
EnableTaskMonitor();
// InitializeNetworkGDB();

eTPUInit();

m_diagFd = eTPUFDUartOpen(4,3,MDCP_BAUDRATE, // 115200
MDCP_DATABITS, // 8
MDCP_PARITY, // no parity
FS_ETPU_PRIORITY_MIDDLE);

When compiled, I/O to the specified UART works as expected. If the 'InitializeNetworkGDB' (or the associated _and_Wait) is uncommented, the debugger works, but the UART does not function (no I/O).

We are a bit puzzled as to the reason and was wondering if there was a solution (except for using lots of iprintf's for debugging).

Just read my earlier post and forgot to mention - it is a MOD5234. We have an RS-422 driver connected to the associated eTPU pins and it works just fine unless debugging is enabled - then no I/O. It is really difficult to debug the interface protocols and the flash file system configuration file parsing and such with just iprintf statements

Hi Ben,

Try this. I am using the eTPU UART's and I had an issue with the debugger not running but never saw your issue as I am using them with debug enabled.

Insert an OSTimeDly(); just after the InitializeNetworkGDB(); and see if this fixes the issue.

InitializeNetworkGDB();
OSTimeDly(1);

Without this delay I can not debug the main task. It could be related to your issue too. Worth a quick try and see.

Dave...

Thanks for the suggestion, I tried it but it didn't work...the debugger works just fine. However, the I/O on the eTPU UART simply appears dead. If I comment out the InitializeNetworkGDB, the eTPU UART works, but, of course, the debugger doesn't work. At a loss as to why the two should have any relation to each other. It seems really strange. We have a TDMA radio using RS-422 connected to the UART and have the TDMA configuration as a file in a flash file system. Trying to debug the details of the radio configuration parser and handling is quite difficult.

Sounds like something in the debugging setup is still stuck on the serial port. The fact that debugging works over TCP argues against that, but it's worth a quick trip to the configuration debug area just to make sure. Maybe try changing some settings and then changing them back?