STLINK-V3PWR API

[PMZ]

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

[S C]

Hello,

First, thank you for your feedbacks.
- A command already exists for disabling the prompt. It is not documented because initially reserved for use by STM32CubeMonitorPwr, but if it can make your life less annoying you can try it: "power_monitor" and "power_monitor off" to restore. Note that it affects some other behaviors compared to what is described in the UM3291 (like for instance the summary contents at the end of the acquisition; but nothing insurmountable).
- I'm not sure having well understood the point regarding the end of line configuration: are you speaking about receive or transmit, with which application ? The V3PWR firmware always answers with CRLF, and should be tolerant to missing CR or LF downstream (however we tested only downstream with CRLF, that's why we recommend this setting in the UM3291). If possible in your configuration it might be interesting to see what really flows at USB level ?

- The example below the table 28 is indeed a typo in the document. Sorry for that

- Timestamping is implicit: the timestamp is the recordId since the acquisition started. The V3PWR firmware does not send any timestamp in the flow (the host has to count what it receives), excepted when the continuity is broken. The V3PWR firmware always increments the timestamp counter (recordId) according to the acquisition sampling rate, even if no associated record is sent. But when the first record after discontinuity is sent, the corresponding timestamp (recordId) is sent in preamble, thus allowing the host to display a "hole", because this timestamp will be greater than recordId+1 of the previous last record received by the host. Measures done during the "hole" (if some were done), are permanently lost (even not stored at V3PWR firmware level). I don't know if it is more clear than what explained in the UM3291, but I don't know how to explain differently ...

Best regards

[PMZ]

- Thanks for the secret command power_monitor 

- timestamping explanation which is much clearer, correct me if I am wrong :

Let say I received n samples in a row and a timestaming frame indicating 42, then the following sample has to be considered as n+42

- Regarding the end of line : when I configure teraterm, which I guess that you are also using, as in the doc (cr+lf) I am getting a blank line after each line.

For instance : here is a piece the help :

################################################################################

# Note: Numerical values of arguments can be formatted either: #

# - Numerical characters only (possible when numbers are >= 1) #

# - Numerical characters with unit characters 'u', 'm', 'k', 'm' #

# - Numerical characters with power of ten '-xx' or '+xx' #

# (xx: number on 2 digits maximum) #

# Example: Value '2 milliseconds' can be entered with: '2m' or '2-3' #

################################################################################

If I setup recieve to Cr only, here is what I get :

################################################################################
# Note: Numerical values of arguments can be formatted either: #
# - Numerical characters only (possible when numbers are >= 1) #
# - Numerical characters with unit characters 'u', 'm', 'k', 'm' #
# - Numerical characters with power of ten '-xx' or '+xx' #
# (xx: number on 2 digits maximum) #
# Example: Value '2 milliseconds' can be entered with: '2m' or '2-3' #
################################################################################

This behavior also happen with my script : like the end of line is \r\n\r\n. The second \r\n is an empty line. But I also wonder if this isnt some kind of magic which, on the computer, convert \r and \n into \r\n each, resulting in two end of line per line. What do you think ?

Regards,

PM

[S C]

Personally I'm using putty but after checking with teraterm I have the same behavior as you. Looking at teraterm help shows that the settings signification is perhaps confusing ? For instance in receive, CR+LF means: "Received CR ($0D) character is converted to CR+LF ($0D $0A) pairs. e.g.) If "CR LF" is received, it is converted to "CR LF LF."

The objective of the UM3291 was to mention that the EOL character in both directions should be "CRLF", but the screen snapshot used to illustrate this is then wrong, according to teraterm behavior. In my understanding of teraterm help, we should rather configure the receive in "CR" or "AUTO" to correctly display in teraterm the CRLF EOL sent by the V3PWR. In transmit I guess the V3PWR advantageously skips empty lines :) I have not understood which configuration to use to have a single CRLF pair sent on each line (would need to set up a trace to check)

Concerning the timestamp, in your example you should receive "n+42" in the timestamp metadata, meaning that 41 records have been lost since you received the nth one

[PMZ]

So, regarding that end of line issue, we are in the "kind of magic" case ... Thanks for noticing this detail, which is unexpeced for me. I suspect my library to have the same be havior.

Thanks for your time.

[PMZ]

I just found out that power_monitor on was changing the summary, which just contains min and max formatted like measurements.

Are there other changes ?

[PMZ]

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]

Hello @S C 

Any updates on these topics ?

Regards,

PM