LAUNCHXL-F28379D: GUI Composer v2 UART monitor not working in online and standalone app

Hello, 

Is the expectation that buffer should hold the same values in both scenarios? The program that you are using to reproduce this issue, is this something that you would be willing to share (privately if you prefer)? It might be quickest way to reproduce the problem. 

Also could you let me know which version of CCS you are using and which version of GC Runtime (standalone)? Also, I am trying to clarify couple of items to make sure we can reproduce the issue:

   You mentioned that you used 432 example. THe processors wiki that you referenced does not have a 432 example. It does have MSP430 example. Is this what you used? 

   There is an MSP432 tutorial that uses UART (same protocol as above referenced Wiki)  However, the target program uses Energia (Wirinig) framework for implementation. Thus I am trying to clarify whether your program is based on Energia or something else and you integrated monitor code into your own application. 

Thank you,
Martin

I used library from Energia - it is in the project linked in your post. Im using CCS 7.3.0 and GC Runtime 5.0.0 (the link to it was provided by https://dev.ti.com/gc/). Here is my project:

UARTmon.zip

It contains CCS and GUI project files. I have new data:

Online GUI composer does 2 16bit writes: 0x000F@0x0005F412 and 0x003F@0x0005F432. Those are MemCfgRegs, and the commands are DxINIT and LSxINIT. Standalone app does 3 more RAM inits: GSxINIT followed by another DxINIT and  LSxINIT.

Those registers are EALLOW protected, so I added EALLOW to write operation. Maybe it suspends communication, because data written is not the one received - those register bits are cleared by hardware after RAM is initialized. Ill try later to fool GUI by sending back not the data from register but the one received.

I've gone through the protocol, even wrote my own monitor dedicated to this uC (faster response). Same results. Here is console from Chrome - for me it looks like it is trying to connect twice to the same COM port.

For now I don't have any ideas how to bite this.

Your last post gave me a bit more information as to what might be happening.

The LaunchPad that you are using is a dual core. In your CCS pictures it looks like you connected/used only one of two cores. However, it looks like GUI Composer is trying to connect to both cores. As far as I can tell physically there is only one COM port that is exposed by the LaunchPad and GC is trying to use the same COM port for both CPUs, which will fail. 

I am assuming that you only care about getting information from that one core. Thus we need to "configure" GC to have only a single core configuration. This should be possible by providing a custom ccxml that bypasses one of two available cores. However, I'll need to test this before I provide you with specific instructions. 

When GC apps run within CCS, they do not start a separate debug connection, they just re-use existing debug connection that user selects in Debug View, thus above problem is bypassed. 

I think this is something else. Tried communication with F28377S and F28069, pictures below. Console on F28069 looks good, but still no reaction on line graph.

////////////////////////////////

There are unfortunately multiple issues that took a while to figure out. 

1. 28379D is a dual core, thus it would require a custom ccxml. This is not supported today on dev.ti.com, we have added support for this internally, but it will take a bit of time for it to be pushed out to dev.ti.com. You have used other single core targets, thus hopefully this is not a show stopper for you. 

2. There is a small bug in firmware where bytes are being transmitted. See function below, without the while loop, FIFO overflows and transmit only works to transfer 8 words (i.e. 16 bytes). Thus if you request an array of 8 elements or under (like tablica ), then it works. For larger memory requests, only 16 bytes are transferred, which then breaks code on the host side as it is waiting for data which it never gets and hence it times out. With the while loop entire bufor array should now work. 

// override these depends on target
void UARTmon::Write8bitByteToCOM(unsigned char c)
{
while(SciaRegs.SCICTL2.bit.TXRDY != 1)
{
}
SciaRegs.SCITXBUF.bit.TXDT = c;
}

3. There is a bug in line graph which expects a multi-dimension array (i.e. X and Y) coordinates. This should work for single dimensional arrays as array index should then be used for X axis. I'll try to provide you with workaround on Monday with some javascript. 

Martin

Thank you for your reply.

ad 1. Is it possible to fool GUI composer by selecting single core device, TMS320F28379S for example? Register map is the same for TMS320F28379D. And if not maybe it would be possible to tie crucial variables to addresses in linker command file in TMS320F28379S and TMS320F28379D projects, and then provide single-core .out file? The thing is that my device will be preprogrammed and only connection used will be UART to read data so GUI composer will need only symbols.

ad 2. Yes, you are correct. Reducing tablica array was done to get around this. I wanted to focus on the connection problem - if it will be fixed I'm going to write my own implementation of UARTmonitor with SYS/BIOS to fully utilize hardware and reduce use of CPU. We (at laboratory) are building a matrix of 9 or more converters and my goal is to build a debug workstation. With GUI standalone COM port can be selected, but tying debug probe by its serial number is not possible like in CCS. And debug probes are expensive ;) There is one possibility that I tested - running GUI application in CCS. CCS instances are not limited, so I can achieve full functionality but at the expense of RAM - standalone application ~20MB and CCS ~500MB. But you will agree that it is not how it should work :)

ad. 3 Is this bug present only with UART connection in GUI standalone and online? I didn't experience it while working with GUI application in CCS.