Help with Javelin Direct C++ Programming

para6654

I have been working on a project to customize / tailor the Javelin Direct programming to my needs. Basically I wanted to take the Javelin Direct code and make it totally C++ by removing the Delphi component ComDrv32.pas.

I replaced the serial port functions in ComDrv32.pas with a C++ library. So far I have been able to get the Javelin Stamp to acknowledge a connection but when the routine called function Reset runs, the response code received is a 0xE3. The response is supposed to be 0x0F. I have debugged the original Javelin Direct (with Delphi) concurrent with my customized version that is all C++. Naturally the original Javelin Direct works fine.

What I would like to know is why the Javelin is returning a 0xE3. What does this mean and how can I fix it?

Any help you could offer would be greatly appreciated.

Peter Verkaik

Are you using the Javelin Demoboard or a usb board like BoE USB?

I think the value 0xE3 is a corrupted value, generated because the
javelin uses its RX line idle state to send data to the pc. So if your pc is
transmitting while the javelin transmits then the pc will receive
corrupted bytes. Check the timing of your C++ uart driver against
the ComDrv32.pas driver.

regards peter

para6654

I am using the Javelin demo board with a USB cable.· The Javelin demo board works fine with the Parallax version of Javelin Direct.· Help me to understand:· by timing, do you mean the timeouts?· The baud rate is 19200 and all of the other com settings are consistent with ComDrv32.pas.·

These are the COM settings I use:

· FComPortHandle··············· = 0;········ // Not connected
· FComPort····················· = pnCOM2;··· // COM 2
· FComPortBaudRate············· = br19200;··· // 9600 bauds
· FComPortDataBits············· = db8BITS;·· // 8 data bits
· FComPortStopBits············· = sb1BITS;·· // 1 stop bit
· FComPortParity··············· = ptNONE;··· // no parity
· FComPortHwHandshaking········ = hhNONE;··· // no hardware handshaking
· FComPortSwHandshaking········ = shNONE;··· // no software handshaking
· FComPortInBufSize············ = 2048;····· // input buffer of 2048 bytes
· FComPortOutBufSize··········· = 2048;····· // output buffer of 2048 bytes
· FPacketSize·················· = -1;······· // don't pack data
· FPacketTimeout··············· = -1;······· // packet timeout disabled
· FPacketMode·················· = pmDiscard; // discard incomplete packets
· FComPortReceiveData·········· = 0;······ // no data handler
· FComPortReceivePacket········ = 0;······ // no data packet handler
· FComPortPollingDelay········· = 50;······· // poll COM port every 50ms
· FOutputTimeout··············· = 4000;····· // output timeout - 4000ms
· FEnableDTROnOpen············· = true;····· // DTR high on connect
· FFirstByteOfPacketTime······· = DWORD(-1); // time not valid


This C++ serial port·software came from a company called Marshallsoft.· They also responded to my question.· Their response was

"
The function SioGetc returns a 32-bit integer. If it is negative, this
indicates either "no data" (value -100) or an error. Otherwise, the
rightmost 8 bits is the data byte. Be sure to always check the return
code.
Note that WSC_NO_DATA is -100. All other negative return codes are
errors.

Note that 0xFFFFFFE3 = -29 would be an error (although there is no
error
-29) while 0x000000E3 would be a data byte.

Until you have this debugged, avoid using SioGets since it doesn't
return
error codes.

"

The response from the Javelin did not appear to be a negative (it appeared to be a 0xE3).· I am guessing that if this is a corrupted value, I would see problems on the connection further upstream that I am not trapping for.·

Peter Verkaik

You got the baudrate all wrong. The javelin communicates with the IDE
using 28800 baud.
By timing I mean the latency.

regards peter

para6654

Peter:

Thanks for the pointer on the baud - that fixed the problem with the initial reply back from the Javelin stamp. I get the correct response (0x0F) now.

I have run into 1 other small (I think) problem with the response. This problem occurs on both the customized Javelin Direct program and the "vanilla" Javelin Direct program from Parallax. Basically the error is an IDE-0056. Javelin Direct seems to have a problem getting a response packet quickly enough.

Interestingly enough, the standard Javelin Stamp IDE does not have this problem. I can debug the LEDButton.class file without any problem in the Javelin Stamp IDE.

What I am wondering at this point is: is it possible to transfer JEMs and/or the base classes to EEPROM to the point that the Javelin Stamp board could ~damaged~?

Thanks in advance.

Peter Verkaik

JavelinDirect, either the original release or my adapted version, download
ok to the javelin. The fact you get error IDE-0056 must therefore originate
from your serial driver. That's why I mentioned the latency.
It is not possible to damage the eeprom because the javelin either
accepts a package and then writes it to eeprom or it doesn't.
The chance the eeprom wears out is identical to using the Javelin IDE.
There is no way to change the javelin firmware by mistake, so you can
always do a new download in case it is unsuccesful.

regards peter

Post Edited (Peter Verkaik) : 5/21/2008 6:31:02 AM GMT

para6654

Thanks.· That's reassuring.· I will continue to debug.

para6654

Peter,

I appreciate your help on this.· I have run into another problem with my custom program.· Communication appears to be working but when I try to download a JEM file, I get an error.·

The error looks like a problem with the serial port driver.· I am posting here to get your insight.· The problem occurs on the TSXComm / ReceiveAck function.· Basically after a handful of acknowledgments, the serial port drive seems to stop responding with valid acknowledgments.· I am wondering if there is a problem with the JEM file that is getting downloaded.

Please see the screen prints attached.

Peter Verkaik

If there were a link error, then no jemfile is generated and no download is started.
So the jemfile is not the problem. Besides that, the javelin receives packages with
a checksum and as long as the checksum matches the packages, the javelin will
send an ack. So it must be your driver code.
You may want to compare the delphi source against your c++ source to see
how the serial driver operates internally.

regards peter

para6654

The standard JavelinDirect that you/Parallax have written works fine with the Delphi serial port driver.· And, it also appears that the alternate serial port driver works since some packets are being acknowledged ~successfully~.· It seems as though around the 18 or 19th packet (about 288 bytes), the acknowledgement fails with a (Marshallsoft) return code of WS_IE_BADID (==-1).··Would it be possible to see the firmware code that processes the packet on the Javelin side?· Is it possible that some of the Jem File is bad?· Can you explain a little more about the checksum?·

Peter Verkaik

The Javelin firmware source is not available. However I did wrote a downloader for
a jemfile to be stored on a propeller that·runs a·jvm.
http://forums.parallax.com/showthread.php?p=703261
That project is still a work in progress but the downloader code is complete.

The calculation of the checksum is done in file TSXComm.cpp in function ComputeChecksum().
This·function is used by·DownloadBreakpoints() and DownloadJemfile() functions.
The checksum is the simply the negative sum of all packetbytes except the last byte
which is the checksumbyte itself. This means adding all bytes from a packet results
in zero for a valid packet.

Since the checksum is calculated prior to sending the packet·you really must
look for a difference between the delphi source and the c++ source regarding
the serial driver. Perhaps you must change some settings. The delphi source
is set to call a handler function upon receipt of 1 byte. Your c++· source
must do the same because otherwise the protocol may fail due to mainline
code waiting for data.

regards peter

para6654

Peter,

Can you give me an idea of what is actually being returned back by the javelin during the ReceiveAck function?· Is it a checksum _or_ is it a packet _or_ something else?· I am getting hung up on the download of the jem file.· I do not understand what the acknowledgement represents.

Peter Verkaik

A positive ack is identified when the javelin returns the commandbyte with b7 set.
You can extract this easily by looking at function receiveAck() in file TSXComm.cpp.

void __fastcall TSXComm::ReceiveAck(int command, int wait )
{
· // Wait for acknowledgement.
· int charTime = GetTickCount(), endTime;
· unsigned char c;

· while ( charTime + wait >= GetTickCount() ) {
··· while ( !CharReady() ) {
······· if ( charTime + wait < GetTickCount() )
········· throw EError(kIDE_ERROR, 22 );
··· }
··· endTime = GetTickCount();

··· c = GetChar();

··· if ( gOptions.debugComLevel >= kDebugComBytes )
····· StatusDebug("TSXComm::received byte $%2.2X '%c' in %dms", c, isprint(c)?c:'.', endTime-charTime);

··· if ( c == (unsigned char)((unsigned char)command|kReplyBit) )
····· return;

··· // We just got an asynchronous message. We can't deal with it here so
··· // pretend we just received a one byte packet and queue it for later.
··· HandlePacket(&c, 1, Linker);
· }

· // We didn't get the reply we expected within the timeout.
· throw EError(kIDE_ERROR, 22 );
}

regards peter

para6654

I apologize for my lack of C++ knowledge.

Is command|kReplyBit = b7?· If command = 0x12 and kReplyBit = 0x80, I don't understand how this adds up?

Peter Verkaik

kReplybit is a constant of value 0x80.
Constants are defined in TSXComm.h file
| is the binary OR operator.
so 0x12 | 0x80 becomes 0x92

regards peter

para6654

OK.· The 0x92 is understood.·

0x80 = 10000000

| (or'd)

0x12 = 00010010

=

0x92 = 10010010



So Bit 7 = left-most significant bit· (as opposed to bit 8) ?

Peter Verkaik

A byte only has bits b0-b7 with b7 being the MSB and b0 the LSB.

regards peter

para6654

Thanks.