eTPU, UART and Debugger

[ben-z.lawrence]

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).

[ben-z.lawrence]

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

[v8dave]

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...

[ben-z.lawrence]

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.

[tod]

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?

DebugConfig.png (31.18 KiB) Viewed 3436 times