Hi everyone,
I am stuck on a Twizy 80 that will not enter GO mode after a failed custom Arduino tuning attempt. I have exhausted every SDO-only recovery I can think of and could really use input from someone with DVT access or a healthy reference Twizy.
--- Vehicle ---
Vehicle: Renault Twizy 80, 2012
Controller: SEVCON Gen4 Size 4, SW 0712.0001 (pre-Jun 2016, unlocked - confirmed writable)
Vendor ID: 0x1E
Product code:
0x0712302D
Revision: 0x00010019
Serial: 0x47976725
Tooling: M5StickC Plus2 + M5 CAN Unit (CA-IS3050G), native ESP32 TWAI driver
@ 500 kbps via OBD-II, no OVMS module installed
Bus access: SDO read/write, NMT Node Reset (target node = 0x01 only, never broadcast)
--- Symptoms ---
STOP indicator permanent on dashboard
No GO possible regardless of key cycle or 12V disconnect
DC bus stuck at ~44 V (pre-charge residue only, main contactor will not close)
Statusword locked at 0x0440 (SW-ON-DIS)
Error register cycles 0x40 / 0x41 / 0x51 depending on recent actions
Battery is healthy (~80% SOC visible on dashboard, ruled out as cause)
--- Background ---
A custom Arduino tuning sketch (a v14 iteration) wrote to 0x3813 sub-indices it
should not have touched. Most damaging: 0x3813:23 = 13000 (intended power
constant). SEVCON internally retained 5506 (= 0x1582) and immediately threw
STOP + SERV. Twizy has been undriveable since.
On a 270-second passive bus scan (TWAI in NO_ACK listen-only mode), the
persistent EMCY observed was:
0x081: CIA=0x6100 (Device Software) reg=0x40
Sevcon=0x4F41 (Internal Fault)
6 frames in 270 sec, ~once per 45 sec
--- Recovery attempts (in order) ---
1. Restored all known v12-convention tuning registers to OEM STOCK:
0x2920:05/06/07/0B/0D/0E/0F/10/03/04, 0x4624:00, 0x4641:02, 0x6075:00,
0x6076:00, 0x2916:01, 0x290A:01/03, 0x291C:02
All 18 writes succeeded, read-back matches.
2. Zero-wrote the v14-touched suspect set 0x3813:01/02/03/04/0E/0F
Accepted (these are RAM and were already 0 by then).
0x3813:23 rejected zero with SDO abort 0x06090032 (value too low)
Minimum is dynamic.
3. Tried CANopen standard restore: 0x1011:01 = "load" (= 0x64616F6C)
Accepted, NMT Node Reset triggered bootup heartbeat in 12 ms.
Effect: 0x4F41 Internal Fault cleared and has not returned (confirmed
with 30-sec post-restore EMCY listen: zero EMCY frames). BUT 0x3813:23
remained at 5506 - the load restore did not touch it.
4. Wrote 0x3813:23 = 6000 (matching its immediate neighbor 0x3813:22 = 6000,
hypothesis "peak >= rated") - accepted, read-back = 6000, NMT reset,
full key-cycle 60 sec off. 0x5044 Param dyn range err STILL active
in 0x5300:03.
--- Current state (read-only scan) ---
========== State scan ==========
Login : OK lvl 4 (operator 0x4BDF)
Statusword : 0x0440 (SW-ON-DIS)
Error reg : 0x40
DC voltage : 43.7 V
Ctrl temp : 0 C (may be below sensor threshold)
-- 0x5300 Active faults --
count (sub 1) : 2
sub 2 = 0x0000 (none)
sub 3 = 0x5044 (Param dyn range err)
-> 0x4F41 NOT present anymore
-- 0x1003 Predefined error field --
(read fails on this SW version)
-- 0x3813 full sub-scan (01..50) --
Sub Value
01 0 (RAM)
02 0
03 0
04 0
05 1024
06 1024
07 32767 \
08 3000 \
09 26214 \
0A 3500 \ set A
0B 16383 /
0C 4500 /
0D 6553 /
0E 0 (RAM)
0F 0
10 0
11 0
12 750
13 750
14 5000
15 0
16 5000
17 500
18 5000
19 26
1A 0
1B 32767 \
1C 3000 \
1D 26214 \
1E 3500 \ set B (identical to set A)
1F 16383 /
20 4500 /
21 6553 /
22 6000 <- rated?
23 6000 <- was 5506, now written = 6000 ***
24 32767
25 3000
26 32767
27 3500
28 32767
29 4500
2A 32767
2B 6000
2C 0
2D 10000 <- max neutral speed per Twizy-Cfg docs
2E 512
2F 512
30 100
31 800
32 900
33 0 (brake-safe)
34 0
35 0
36 160
37 100
38 30000
39 32767
3A 32767
3B 65535 (brake-safe)
3C 65535 (brake-safe)
-- Tuning registers (all STOCK confirmed) --
0x2920:05 SPD_MAX : 7250
0x2920:06 SPD_REV : 900
0x4624:00 SPD_OVR : 11000
0x4641:02 CUR_STA : 450
0x6075:00 CUR_LIM : 450000
0x6076:00 TRQ_MAX : 55000
0x2916:01 TRQ_RT : 57000
0x2920:03 RGN_NEU : 182
0x2920:04 RGN_BRK : 800
0x290A:01 RGN_MD : 2
0x290A:03 RGN_TH : 560
0x291C:02 RMP_STR : 400
0x2920:07 RMP_ACC : 2500
0x2920:0B..0x10 : 2000, 4000, 4000, 6000, 6000
-- EMCY scan (5 sec passive) --
0 unique, 0 frames total (SEVCON no longer emits emergency)
==========================================
--- What I am hoping for ---
The OVMS docs state 0x5044's diagnostic is only visible via the DVT CLI window:
"At least one configuration object is out of dynamic range. Engineering DVT
CLI window indicates type of object which is out of range."
Without DVT I must guess which object pair conflicts. In 0x3813 I see set A
(0x07..0x0D) and set B (0x1B..0x21) are identical OEM blocks after the load
restore. The only oddball pair is 0x22 / 0x23. Writing 0x23 = 6000 to match
0x22 was accepted but did not clear 0x5044 - so the constraint is more
complex than simply 0x23 >= 0x22.
Specific questions:
1. What is 0x3813:23 actually defined as? Twizy-Cfg source documents
0x3813:2D = max neutral speed = 10000 rpm but does not enumerate
0x22 or 0x23. Is this power, RPM, or something else entirely?
2. Could anyone with a stock-tuned Twizy 80 (especially SW 0712.0001)
share their 0x3813:22 and 0x3813:23 values? With the exact OEM number
I could try writing it directly and let 0x5044 self-clear.
3. Is there a clear-DTC command for 0x5300 besides the natural "condition
gone" mechanism? Or a write target that forces re-evaluation of all
dynamic-range checks?
4. Has anyone seen 0x5044 survive a successful 0x1011:01 = "load" restore?
In my case it did - suggesting 0x3813:23 = 5506 is stored in a sector
that the CANopen restore does not reach.
I have working Arduino sketches ready (read-only explorer, targeted writers
with read-back) for any test you suggest. Happy to share source.
Thanks in advance. Remaining alternatives are a Renault dealer with
CLIP/DDT2000 or buying into DVT, but I would prefer the community route
first since the SEVCON itself appears healthy (responds to all SDO,
boots cleanly on NMT reset, no longer emits EMCY at all).
Cheers,
TechnoP
--- Update: further experiments and what we've eliminated ---
Following up on my original post with two additional rounds of experiments. The Twizy is unchanged in driveability (still STOP, no GO), but we have ruled out several hypotheses and uncovered some interesting register behavior. Hoping this narrows things down for anyone with DVT access.
### Round 1 — PMAP/FMAP restore (v12-source defaults)
Inspection revealed the PMAP at 0x4611:01..0x12 was corrupted by the failed
v14 sketch. Specifically, sub 0x12 (last point) was 8156 RPM, which is
exactly (T80_RPM_MAX * 90 + 40) / 80 = the v14 SPORT-mode formula for
90 km/h. So v14 had calculated and written its own power map.
Restored the v12-source OEM PMAP and FMAP:
PMAP 0x4611:01..0x12 (18 values, torque/RPM pairs):
880, 0, 880, 2115, 659, 2700, 608, 3000, 516, 3500,
421, 4500, 360, 5500, 307, 6500, 273, 7250
FMAP 0x4610:0F..0x12:
964, 9728, 1122, 9984
All 18 + 4 writes succeeded, read-back exact match.
Result: 0x5044 unchanged. PMAP corruption was real, but not the trigger
for 0x5044.
### Round 2 — 0x3813:23 = 18000 (OEM peak power per OVMS User Guide)
The OVMS User Guide RT3.8.3 explicitly states:
"The SEVCON will limit motor power levels to the 'motor peak electrical
power' as configured in SDO 0x3813.23 which defaults to 18000 W."
My earlier write of 6000 (to match 0x3813:22) was therefore probably wrong.
Wrote 0x3813:23 = 18000 in pre-op, NMT Node Reset, key cycle.
Write: accepted, abort=0x00000000
Read-back: 18000 exact (no clipping)
Persistent across key cycle: yes (still 18000 after full power-down)
Result: 0x5044 unchanged.
This means we now have two independent configurations both triggering
0x5044:
0x3813:22 = 6000, 0x3813:23 = 6000 -> 0x5044 active
0x3813:22 = 6000, 0x3813:23 = 18000 -> 0x5044 active
Conclusion: 0x3813:22 / 0x3813:23 is NOT the conflicting pair. The
dynamic range check is on a different object.
### Round 3 — Attempted log/fault clear (per dexter's guidance)
You pointed at registers 0x4100, 0x4110, 0x4200, 0x4300, 0x5300 in the
Estrima Biro thread (node/2626). I tried writing 0 to the count
sub-indices to clear:
0x4110:02 (faults log count, was 40) <- 0 : FAIL abort 0x06010002 (Read-only)
0x4100:02 (system log count, was 10) <- 0 : FAIL abort 0x06010002 (Read-only)
0x5300:01 (active fault count, was 2) <- 0 : FAIL abort 0x06010002 (Read-only)
All three counts are read-only at operator level (0x4BDF / lvl 4).
Side effect: active fault count went from 2 to 4 and is persistent across
key cycle. Sub 02 still shows 0x0000 placeholder, sub 03 still 0x5044, but
count = 4 suggests two more entries that my sketch cannot read (probably
SDO abort on sub 04 / 05 -- can verify if helpful).
DC voltage and ER recovered after a 2-hour key-off rest:
DC: 34.7 V (just after experiments) -> 40.7 V (after rest)
ER: 0x51 unchanged
Hardware appears unharmed. Sevcon still responds cleanly to all SDO, NMT
boots in 4-12 ms, no EMCY spam (only the expected 0x4681 "Preop"
notification when we trigger pre-op).
### What we now know
- 0x3813:23 is fully writable in a wide range (tested 6000 and 18000,
both accepted exactly, no clipping). v12-source comment "do not write
- causes STOP" is too conservative for the write itself; v14's STOP
was likely from PMAP corruption combined with the write, not the
write alone.
- 0x3813:22 / :23 is eliminated as the conflicting pair for 0x5044.
- Logs 0x4100, 0x4110 and active fault list 0x5300 are read-only via
SDO at operator level. The OVMS "xrt cfg clearlogs" command must
therefore use a different mechanism -- engineering access level?
OBD2 with Renault-specific request? PDO trigger?
### Specific questions for anyone with DVT or a healthy reference Twizy
1. Most useful: if anyone runs DVT on a Twizy with a known 0x5044,
the CLI Engineering window names the offending object. Even a single
hint ("it's in object 0x__:__") would let me focus the search.
2. How does `xrt cfg clearlogs` clear the fault list internally?
Does it use access level 5, a specific OBD2 request, or a higher-level
SDO write target that I'm missing? Even pseudo-code of the operation
sequence would help me port it to the M5StickC.
3. From any healthy Twizy 80, SW 0712.0001 or 0712.0002: would you be
willing to dump 0x3813:01..0x3F and 0x4611:01..0x12 so I can compare
against my restored values? Currently using v12-source defaults but
I have no live reference to confirm those are correct for this SW
version specifically.
4. Is there any non-DVT path to trigger a full "re-evaluate all dynamic
range constraints" without an NMT reset? NMT reset re-evaluates but
apparently doesn't help if the underlying object pair is still
out-of-range.
All Arduino source (M5StickC Plus2 with M5 CAN Unit, native ESP32 TWAI
@ 500 kbps, no MCP2515) is available -- happy to share read-only scan
and targeted write sketches for any experiment suggested. The sketches
follow the v12 OVMS write conventions (login 0x4BDF, pre-op via
0x2800:00, NMT Node Reset 0x81 targeted at node 1 only).
Sevcon itself appears healthy. Just need to identify the right register
pair.
Thanks,
TechnoP