Skip to content

Release v0.20.0 and safety firmware v0.4.0 - #10

Open
mhei wants to merge 30 commits into
mainfrom
feature/for-release-0.20.0
Open

mhei wants to merge 30 commits into
mainfrom
feature/for-release-0.20.0

Conversation

@mhei

@mhei mhei commented Sep 7, 2026

Copy link
Copy Markdown
Member

This PR adds support for upcoming configuration features of the safety firmware and the new safety firmware itself.

mhei added 23 commits July 15, 2026 14:16
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>
Comment thread lib/cb_protocol.h
INLET_STATE_OPENING = 0x2,
INLET_STATE_CLOSED = 0x3,
INLET_STATE_CLOSING = 0x4,
INLET_STATE_ERROR = 0x5,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gap at 0x6 is intended?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, due to the 3-bit field in the message.

Comment thread lib/cb_protocol.c
@@ -982,24 +982,29 @@ void cb_proto_dump(struct safety_controller *ctx)
unsigned int i;

if (!ctx->mcs) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this change, but I would prefer to swap cases here for better readability

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread lib/cb_protocol.c
case 5:
case 6:
case 7:
return errmsg_append_u32(buffer, size, &first, "FSP error code", additional_data_1);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FSP?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread README.md
- Scalar form: `disabled`, `disable`, `none`, or `off`
- Mapping form:
- `abort-temperature`: temperature in `°C`
- `resistance-offset`: resistance offset in `Ω` or `Ω`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both symbols look identical, is this intended?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/param_block.c
!(strcmp(endptr, "%") == 0 || strcmp(endptr, " %") == 0))
return -1;

if (val < 0 || val > 100)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Controversial: yes 0 and 100 are valid values, but shouldn't give some kind of warning?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Comment thread firmware/CMakeLists.txt
install(
FILES
chargesom_fw_v_00_03_01.bin
chargesom_fw_v_00_04_00.bin

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please specify the RX timeout in the commit message?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment thread src/param_block.c
param_block->crc = crc;

if (fwrite(param_block, sizeof(*param_block), 1, f) != 1)
return -1;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly related to this change: Is there at least a chance to factor out this fwrite part?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
@mhei
mhei force-pushed the feature/for-release-0.20.0 branch from 2bedf53 to 35dc1df Compare September 15, 2026 13:00
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants