cancel
Showing results for 
Search instead for 
Did you mean: 

STLINK-V3PWR API

PMZ
Associate III

I've started using the recently published UM3291 to have smoother workflows with my other acquisition tools

 

There are a few glitches that makes life a little bit more annoying than it should be.

- The first one beeing the prompt "stlp >", which has to be filtered out. A disable prompt would save some code.

Especially when using command during ascii streaming where it prefixes a measurement when sending a command like targrst.

- The new line configuration works better when setting CR or LF rather than CR+LF. Otherwise, there is one blank line after each line with content.

- The table 28 gives ascii data format. The example does not match that format.

According to the table, the lenght is always 8 characters. The example is 7 character long. The byte 6 is missing (-7, instead of -07).

- There should be a response pattern : [ack|error] [command] : [response]. Some commands do not match such a pattern, like whoami, echo, pwrend. Status command do match, but it does not appear clearly.

- Timestamp usage is hard to understand.

I understand that between the last received sample and the Timestamp message received a number of RecordId samples are missing. Thus, these samples can be replaced by the last known value or something else.

Is this correct ?

 

I'll test binary streaming later, when I understand the usage well enough in ascii mode.

 

Regards,

PM

12 REPLIES 12
S C
ST Employee

OK this bug will be fixed in next firmware version, which should be "P6". If you want to manage it from now on, I'm afraid you will need to implement both ways of processing depending if the "P" version is less than 6 or not [Note that I have not decided yet if the firmware will answer 5 bytes starting by F0 F9 or 6 bytes starting by F0 F7 in this case].

The bug is not an alignment issue (the firmware is transferring bytes), but a wrong formatting of the metadata packet in this case. On your side do you expect to get records on a 2-bytes aligned address ? I'm afraid the current metadata format does not guaranty this.

I have to discuss with the team about your use case, I would be happy if it already works like that, but I'm afraid it's currently a "border line usage", which would at least require validation at our level (as you can see ...).

I hope this will help; please keep me informed of your progress

PMZ
Associate III

Hello, 

I can query the protocol version to handle booth protocols, no problems.

I dont expect to have data alignment over two bytes. My protocol layer reads binary metadata until ffff, after that, the protocol is either two data bytes or two metadata start bytes.

I am not in a hurry for the fix because i'm in vacation for the next two weeks, also there will be no updates until early to mid June

Thanks for the fix, btw.

 

PM

PMZ
Associate III

Hello @S C 

Any updates on these topics ?

Regards,

PM