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 · Accepted solution]

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 ?

[S C]

Hello,

Yes I mentioned it in my first answer. After quick review this should also affect the acknowledgment of the stop command and bypasses some consistency checks done by freq, acqtime, output and format commands; so you have to take care, in this case, not saturating the channel by configuring a too high sampling freq in ascii format for instance (if implementing a tool, I recommend to support only the binary format in the acquisition interface, even with low frequencies, then implement your own formatting/display above the acquisition interface).

Note that the command power_monitor is not documented because we want to keep some freedom adapting the interface for STM32CubeMonitorPwr if required, without impacting the documented API. We won't change things only for fun, but I prefer warning you that there is a (little) risk that you should accept when using this command.

[PMZ]

One more question: I am streaming binary data. While the stream is ongoing, I change the voltage level, using volt ascii command.

I am getting the expected 0xF9 0xF0 0x01 0xFF 0xFF, but after that, there is one more byte which I have to trash other wise, this byte will shift the data forever, breaking the protocol and further data extraction.

Even calling vout a second time does not shift a second time and sets data in the proper way.

The attached spreadsheet is the binary measurement data. In the NOK sheet, the spurious byte is not read. In the OK sheet, the spurious byte is read and discarded.

In columns G/H/I we can see the request then the response, with the unexpected byte value.

At sample # 100 we can see the data1 value of 160 in the NOK sheet. After that, we can see the one byte shift easily because of the 88 value wich is not in the same column again.
That does not appear in the OK sheet.

Since the protocol is based on two bytes read, it is definitively broken.

At #120, the behavior is different because of the shift that also breaks the parsing of the binary response 0xF9 0xF0. We can see the bytes in data1 and data2, but parsing is broken.

Interesting to note that at #100, the value is always 160, at #120, it is always 160, at #140 it is always 220. This is valid from a run to another, from a powercycle to another.

Do you have an idea of what is going on ? Do you observe the same on your side ?

Regards,

Pierre

[S C]

Hello,

This raises 2 points:

1. We have not validated the voltage change during acquisition because this case is not possible in CubeMonitorPwr context

2. However some code is available at firmware level around this ... but is buggy: it mixes the metadata for "pwr get" command (5 bytes starting by F0 F9) and metadata for "voltage get" command (6 bytes starting by F0 F7). At the end it prepares a 6-bytes message but affects only 5 ...

This use case is not clearly specified; theoretically it should trigger an automatic calibration after the "volt set" command, potentially generating overflow depending on the sampling frequency, thus also timestamp metadata packet: lot of reasons for other bugs, if not validated (currently I only reviewed the source code). I can fix the "easy" issue with 6 bytes versus 5 bytes in the metadata packet. But if we want to make it a feature, it will need further validation, I can't commit on that yet, at least for the next firmware version. May you please detail your use case, or have you tried this command "just to see" ?

[PMZ]

Hello,

Thanks for confirming the bug. I suppose that this will be the same for all even sized responses.

I have a real use case : my product is expected to have two batteries, and i need to check that whichever the voltages levels, it will work as expected.

Moreover, I intend to evaluate the device capability to mimic an accelerated end of battery life, and check that all compensation work as expected.

Regards,

PM