Forums

When I am sending the example HEX codes given in the user guide I am getting the response as it should give.

For eg:- If I send FF 06 85 00 02 02 00 08

The motor controller responds with the following :- FF 04 05 20 02 02.

But the motor is not running and I am getting the Flashing yellow light.

Don't have your board - but some background/skill in motor control.   You succeed w/ TI GUI - does that also exercise the serial port?  If so - cannot you monitor and "sniff" that serial port during a successful transaction - and log that (successful) data?  Possibly some special start and/or ending character is employed - this logging method would capture & reveal.  (best if you can "sniff/log" all serial transactions - not just "printable" ASCII.  May be control codes interposed)

Haven't heard/used Docklight - can you use it while running TI GUI?  If not - Hyper-Terminal & other free serial enabled programs are available.  You may wish to "sniff" with a 2nd PC - be sure that each PC has common ground or optically connect or otherwise "isolate" interconnects.

"You succeed w/ TI GUI - does tdsjbfijdskvbhat also exercise the serial port? "

Yes it does.

Yes I tried it with docklight the "sniff/log" serial transaction thing. But when I turn on the connection with the TI GUI it sends data continuously so I am not able to interpret which data(HEX code) is for what purpose.

Sanjeet Kulkarni

the TI GUI it sends data continuously

Well that's not expected - and corrupts my past suggestion.  (but may indicate the regular "update" between GUI and remote device.)  Perhaps there is one or several commands which limit this flow of data?  You'll have to study further or exercise each command in sequence - trying to resolve.  While not thrilled - you should be able to launch the GUI and then quickly, "pull the RS232 cable" - interrupting the flow of data.  Done quickly enough - this should limit the volume of data captured - better enabling your detective efforts...

The source code of the GUI application is included in SW\tools\rdk-bdc if i remember well and this application can be also called from command line.

Petrei

Petrei

source code of the GUI application is included

Hi Petrei - follow many of your posts - you are always helpful - make a nice difference.  Thank you.

Now - I have not known any of the Stellaris specific GUI Aps to provide and/or release their PC side source code!  May I ask if this is what you are stating?  I can tell you that I have read/re-read the bldc-rdk code so many times - (sheep in my dreams now have semi-colons for tails) and not one hint of PC side code is revealed.  And it would - of course - be helpful and instructive - but not to hold one's breath...

I'm instead believing you meant the Stellaris side (how Stellaris MCU interacts) has its source code supplied.  Possibly Stellaris is demanding the "machine-gun" data transmissions between PC & Stellaris.   But I doubt that - my belief remains that the PC is most always, "the boss of me." 

Instead of trying to just pull out the RS-232 cable I pressed the disconnect button so as to limit my data to fewer command than before.

Attached is the .txt file of the data sent by GUI to the motor just after establishing the connection.This data was collected over a period of 5 3 seconds.

Should we disable the heartbeat of the Jaguar?

Does it wait for some command to come in active mode?

Instead of trying to just pull out the RS-232 cable I pressed the disconnect button so as to limit my data to fewer command than before.

Attached is the .txt file of the data sent by GUI to the motor just after establishing the connection.This data was collected over a period of 3 seconds.

Should we disable the heartbeat of the Jaguar?

Does it wait for some command to come in active mode?

6354.gui.txt

I am sorry for the typing mistakes.

Ok - good job - thank you.  Your file "capture" appears to reveal that "checksum" is not used - or at least that it is not placed in "normal/customary" end of line, byte position.  I have not yet made the time to review your board's command structure - your capture suggests that 0XFF is the command start byte and 2nd byte is command, "identifier."  Further bytes provide parameter data - used by specific commands.

With this as explanation - carefully compare your, "Command Packet Listing" with those in this text capture file.  Are they identical?

Do note several Command & Identifier repetitions.  (what's up with that?)  Look at "FF 06 xxxx" - starting @ 13th line from the top - continuing to the 18th line.  Thus - this command - with parameter changes - is sent 6 times - back to back?  Question to ask - Why?  What does this command seek to accomplish?  My sense is that your focus on this particular command may prove instructive. 

Have you seriously (via single tasking) read & studied the comprehensive User Guide and/or Manuals?  We know that others have succeeded - often some minimal effort is required to, "make the mental connection."  Good luck...

Hi,
@cb1_mobile:

Thanks for your appreciation.
No, it is not what i meant - just suggesting an easier way; after sniffing the problem of de-coding
is still present.

In bdc-comm.cxx i found this function:
UARTSendMessage(unsigned long ulID, unsigned char *pucData, unsigned long ulDataLength)
and serched where and how it is used - it is used many times, like this(as example):
UARTSendMessage(LM_API_VOLT_SET_RAMP | g_ulID, (unsigned char *)plValue, 2);

so LM_API_VOLT_SET_RAMP | g_ulID is the command code - and at this stage I concluded that by simple
preprocessing this file can reveal all command codes.

@Sanjeet:

In your test, try to replace 0x85 with 0x80 - since in that example you've found in the user guide the ID of the board is set at 0x05, but your board is still at 0x00.

Petrei 

Petrei

simple
preprocessing this file can reveal all command codes.

That's certainly good info - however it's really neither efficient nor user-friendly - should that be the only/best means to determine needed, "Command Codes."  (would be the first time I've ever encountered - w/ > 20 years in control electronics)  Such tactic is usually reserved for, Reverse Engineering - surely not a commercial product - meant to be instructive.

I looked again @ poster's serial capture - saw no occurrence of 0x85 nor 0x80 - and this was during a successful GUI to MCU data transaction.  So I remain (for now) dead in the water...

I think it is not reverse-engineering since the source code is provided. Pre-processing of this file is only meant to translate the #defines in various files from symbolic to real data. One mention: I did not investigated, but just observed from the microcontroller side of view, there are some common files with the same defines. 

The second post of op is:

For eg:- If I send FF 06 85 00 02 02 00 08 

the FF is the start of the frame; 06 is the length of the frame, 4+number of bytes after ID(max 8); 85 00 02 02 is the command code | boardID, 29 bits extended ID, (CAN), little endian; 00 08 is the required voltage.

Petrei

We are now talking bit at cross-purposes (2 would be helpers) while poster is silent.  I did not characterize the RDK nor its manual as "reverse" - instead I stated that Command Listings should not have to employ such efforts to clearly view & exploit.  (and there is big difference)

Now - poster's "serial data capture" shows:  (these are the 6 "back to back" Command-ID bytes I mentioned earlier)

FF 06 C1 1D 02 02 00 0C
FF 06 01 1E 02 02 B8 0B
FF 06 01 18 02 02 00 00
FF 06 41 18 02 02 00 00
FF 06 81 18 02 02 00 00
FF 06 C1 18 02 02 00 00

Now - note not a single 85 (or 80) in 3rd byte position!   And poster states that this code transaction did work!  (or so he thought)

Further - I went thru first 200 or so captures - not once did FF 85 nor FF 80 appear!

Must assume that while I've not looked at User Manual - others have not looked at his serial capture...  And we're still stuck...

Now I understand you - but I always put the computer at repetitive work to do it instead of me...

As for "85": the original poster just applied the command given in the user's guide, without reading previous rows, which states: "Some examples to clarify the packet format (all sent to ID 5):" - and afer reading his listing I realized that his board address is not 0x05 - and not looking into the right place I concluded that the address is 0; now looking at your excerpt it is clear the address is 0x01 - and ORed with the command ID gives always something ending with 1 in the third byte (C1, 01, 81..) - my mistake, sorry.

Petrei

Petrei

I always put the computer at repetitive work

Have to challenge - do you characterize a clear, "Command Listing & Execution" table as, "repetitive?"  (think not)  If such a table is "hidden" - that is in severe violation of major Sales Principle, "Provide Comfort & Convenience," for the client - and should be corrected.  (even big firm can miss crucial points) 

You (and I) most always are, "trying to assist others," thus sorrow never sought - clear thinking and problem solving (to the benefit of many) are neat goal - self-rewarding...

Can you analyze this: earlier poster reported sending: "FF 06 85 00 02 02 00 08" - and not getting desired motor/board behavior?  By your explanation - 3rd byte (85) should be legal/proper - thus issue still confounds...