i386 ecos Target

[MarM]

Hello,

Recently i was busy with creating Target based on Ecos and PC i386 machine. I have correct ecos and redboot images. I’m able to create application in LV, build it, load it vi redboot and start (with go command). Next step was Instrumented debugging. As my Template target was cmd565 RAM, I expected that debugging will just work but its not. Situation is following: Host side communication layer seems to work fine. I after downloading via Redboot finishes I get screen  “connecting to target” and my debugging serial port is printing “AT” in loop but there is no rection form Target. Therefore I suspect Target side comm layer. My compiler flags are following:

-DUsesSerialDebugger -DDBGBAUD=38400 -DSocketSupport=0 -DFileSupport=0 -DCHeadless=1 -I.

As I use 38400 in my ecos and redboot images.

Of course in my build configuration I checked: “Generate debug info”. I didn’t modify SerialMessaging.c as I use the same flags for compiler. What do wrong here??? Thanks in advance for any helpJ

Marcin

[Michael.Phillips]

Hi Marcin

There are two things that might cause problems:

1. In PDADebugOpenSerial (SerialMessaging.c) the stop bits should be initialized to 0 not 1. A 1 actually means 1.5 stop bits.
eRunStatus PDADebugOpenSerial()
    {
    SerialConfig scfg;
    int port = 0;
    DEBUG_LOG3(("PDADebugOpenSerial begin\n"));
    scfg.baudrate = DBGBAUD;
    scfg.data_bits = 8;
    scfg.stop_bits = 0;
    scfg.parity = 0;

2. Inside the same function (PDADebugOpenSerial) there is some code that tries to get the port on which the download was done and use that for debug. If FPP_ON_DOWNLOAD_PORT is defined as 0 then it would use the second serial port. This "magic" might not work for i386 ecos simulated target or it might need some tweaking. For debugging the serial debug this port could be set to a known value.

[MarM]

Michael,

I’ve applied your both suggestions but still no results. What I modified in SerialMessaging.c is:

            scfg.stop_bits = 0;

and:

//now direct diagnostic output to the other channel.

            //CYGACC_CALL_IF_SET_CONSOLE_COMM(1 - port);

            CYGACC_CALL_IF_SET_CONSOLE_COMM(0);

But still no result. I’ve tried also to download application via second com port. The strange thing is that when I put in my vi inline C node with: printf(“\nString”);

I can see this output on second (the other one than download) console after issuing “go” command. I’ve add also LogPDAMessages=True to my LabVIEW.ini but no log file is generated (or at least I cannot find it). My last doubt is: Why do you call i386 “simulated target”???? I use real PC with 2 serial ports and with redboot floppy image as i386 target.

Marcin

[pjtanz]

Sorry to weigh in late, but there are a couple of things that I can think of that could possibly be causing problems.

(1)  The CMD565 is a PPC part which is BigEndian. The x86 part that you are porting to is Little Endian.   The LabVIEW Runtime Library will need to be told that this is the case by defining BigEndian=0 at compile time.

(2)  In your Debug.vi, are you calling NiStartSerialDebug before or after you run the application?  It should be after.

(3)  Do you have NI-VISA installed?  If not, there's your issue?

(4)  Are you using a USB-Serial converter?  I have seen issues with some converters that seem to work with Hyperterminal but don't work so well with NI-VISA on the host PC.

I hope that this helps,
P.J.

[MarM]

P.J.,

@(1) I don’t think it is a case as I’m able to run program written in LV on my i386 target. So if I make ‘build’ and create executable then I download it to may target running Redboot, via hyper terminal with yMODEM, with command: load –v –m yMODEM, when its finised I can see my application running (in while loop I have delay 1000ms and inline c node with printf(“\nString”) inside I see this output on second com port. At this point I’ve tried also to convert .exe (ELF) file created by gcc to .srec file (which is 5 times smaller). Application runs in both cases.

@(2)I call it after I run app

@(3)Yes I do, host serial communication is not a problem as I wrote in beginning of this thread

@(4)Well, it can be always a case but I use my usb converters with visa also for some other projects and they work fine

Thanx for response!!!    

Marcin

[MarM]

Hello,

I found reason of my problems:

In SerialMessaging.c you have this PDADebugOpenSerial() which calls SerialOpen_plat(port, &gSer);

SerialOpen_plat uses cyg_io_lookup() for searching for com ports assuming that name of serial device is /dev/serx where x is number. That works but only when you have included serial devices in ecos kernel so it was my error that I didn’t check serial devices in ecos configtool. Thank you once again for your support!!

BTW, I have run it also on LPC-H2294 Olimex board but instead of using redboot I just program flash with executable with debug option. Not very healthy for my flash but its only a matter of tuning..

Marcin