Conversation
The inlet configuration allows to specify whether a lock is used or not. This is intended to cover AC use-cases. The driving time for both opening and closing the lock can be configured. The lock may or may not have a feedback contact which is evaluated with an ADC channel. When a feedback is used, the it is required to specify voltage ranges for "locked" and "unlocked" cases. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
While at, move Proximity Pilot to previous line to save one line. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
It was decided that the parameter block version v2 only include the RCM related configuration. For the upcoming inlet support (plug lock), the parameter block version 3 will be used. So, split the implementation accordingly. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Switch to the term "pluglock" instead of "inlet" in YAML and various visible error messages. Users are more familiar with it on EVSE side compared to "inlet" which is more often used on EV side. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This change is coming with a big difference in the binary representation: the former individual arrays are not reworked into a struct per contactor. And then there is an array with three contactor configurations elements. Since there is no official firmware release with parameter block v3 yet, we don't need any backwards compatible code and/or migrations. This 'economizer' feature is only available with Charge SOM hardware revision V1R2a or later and with matching safety controller firmware. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
The safety controller can monitor the feedback pin of the eg. DRV8876. It is only reported once for every pluglock move request with an error message frame, but has no further impact. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This is important e.g. when safety firmware and this library are out-of-sync, e.g. when dealing with older or development firmware versions. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
For the error frames which make use of additional data fields, add helper functionality to generate and better human-readable error message where the extra data is interpreted. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This tool is intended to support manual debugging of safety controller communication issues. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Usually root permissions are needed for capturing. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
| INLET_STATE_OPENING = 0x2, | ||
| INLET_STATE_CLOSED = 0x3, | ||
| INLET_STATE_CLOSING = 0x4, | ||
| INLET_STATE_ERROR = 0x5, |
There was a problem hiding this comment.
The gap at 0x6 is intended?
There was a problem hiding this comment.
Yes, due to the 3-bit field in the message.
| @@ -982,24 +982,29 @@ void cb_proto_dump(struct safety_controller *ctx) | |||
| unsigned int i; | |||
|
|
|||
| if (!ctx->mcs) { | |||
There was a problem hiding this comment.
Not related to this change, but I would prefer to swap cases here for better readability
There was a problem hiding this comment.
Well, the case without MCS existed prior to the MCS case and would have made the differences between the older commits harder to understand. However, I agree that the entire function has grown significantly in the meantime and has become kind of "fat"... Perhaps we can resolve this more cleanly later on during a cleanup.
| case 5: | ||
| case 6: | ||
| case 7: | ||
| return errmsg_append_u32(buffer, size, &first, "FSP error code", additional_data_1); |
There was a problem hiding this comment.
I guess that FSP stands for "Flexible Software Package" - part of the Renesas SDK for the safety controller. But honestly, I don't care here much because we just log these errors for the moment and can document it later.
| - Scalar form: `disabled`, `disable`, `none`, or `off` | ||
| - Mapping form: | ||
| - `abort-temperature`: temperature in `°C` | ||
| - `resistance-offset`: resistance offset in `Ω` or `Ω` |
There was a problem hiding this comment.
Both symbols look identical, is this intended?
There was a problem hiding this comment.
Yes. One is the greek letter, the other one is the unit symbol. Both binary encoding differ in UTF-8. I want to support both for user convenience.
| !(strcmp(endptr, "%") == 0 || strcmp(endptr, " %") == 0)) | ||
| return -1; | ||
|
|
||
| if (val < 0 || val > 100) |
There was a problem hiding this comment.
Controversial: yes 0 and 100 are valid values, but shouldn't give some kind of warning?
There was a problem hiding this comment.
There is an error message during creation of the PB when values outside this range are used. 100% is a perfectly valid value, but I agree that values < 10 % are most probably wrong. So I'd accept those values, but emit a warning in that case...
| install( | ||
| FILES | ||
| chargesom_fw_v_00_03_01.bin | ||
| chargesom_fw_v_00_04_00.bin |
There was a problem hiding this comment.
Could you please specify the RX timeout in the commit message?
| param_block->crc = crc; | ||
|
|
||
| if (fwrite(param_block, sizeof(*param_block), 1, f) != 1) | ||
| return -1; |
There was a problem hiding this comment.
Not directly related to this change: Is there at least a chance to factor out this fwrite part?
There was a problem hiding this comment.
Could you please elaborate in which direction you're thinking?
This allows to create parameter block binary files with a fixed and thus wrong CRC. Only for testing purpose! Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Changelog for Charge SOM platform (since 0.3.1): - requires parameter block version v2 - enter safe state on UART RX timeout (250 ms) - support for RCMs Changelog for Charge Control Y (parsley) (since 0.3.1): - requires parameter block version v2 - enter safe state on UART RX timeout (250 ms) Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
2bedf53 to
35dc1df
Compare
While we don't know which contactors are used and how good they are optimized when using a PWM driven controlling, value below 10 % are probably wrong, so let's at least warn then. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
The assumption that we always are in sync with the safety firmware, especially due to the fact that we control the reset of the MCU, is given up - instead we try to re-sync on a received frame within our timeout window based on SOF, EOF and CRC. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
The IMD input signal is similar to the usual ESTOPx signals, but dedicated for use with an IMD. The position in the Charge State frame was chosen to be in-line with the other ESTOPs, so the RCM State was moved. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This PR adds support for upcoming configuration features of the safety firmware and the new safety firmware itself.