maxikrie opened a new pull request, #20911:
URL: https://github.com/apache/nuttx/pull/20911
## Summary
`esp32s3_twaiinitialize()` configures the GPIOs and then programs the TWAI
controller (`esp32s3twai_reset()`) without first enabling the peripheral
clock or releasing the peripheral from reset. `esp32s3_start()` calls
`esp_perip_clk_init()`, which on a power-on reset clears
`SYSTEM_TWAI_CLK_EN` and sets `SYSTEM_TWAI_RST`, so the driver runs against
a gated peripheral:
- none of the register writes take effect (bit timing, mode, interrupt
enable), and every TWAI register reads back the same stale value;
- on the bus the controller neither receives nor acknowledges frames, so a
peer keeps retransmitting its first frame indefinitely;
- `CANIOC_GET_BITTIMING` reports a nonsense rate (809 bit/s with
`CONFIG_ESP32S3_TWAI_BITRATE=500000`, decoded from the stale value).
The first commit enables the clock and deasserts the reset in
`esp32s3_twaiinitialize()` before the first register access. The ESP32
(`esp32_twai.c`) and ESP32-S2 (`esp32s2_twai.c`) drivers already do this.
The second commit fixes the three existing nxstyle errors in
`esp32s3_twai.c` (a declaration after a statement, and two single-line
`if` statements), which `checkpatch.sh` otherwise reports for any change to
the file. No functional change.
## Impact
- ESP32-S3 TWAI/CAN works after a power-on reset. Before, it could only
appear to work after a software reset from firmware that had already
enabled the clock (`esp_perip_clk_init()` gates only clocks that are
already off on non-power-on resets).
- No change to other chips, Kconfig, the build or documentation.
## Testing
Host: Debian 12 (Linux 6.1, x86_64), Espressif toolchain
`xtensa-esp-elf` esp-14.2.0_20241119.
Build: `esp32s3-devkit:twai` on current master with both commits:
compiles and links with no warnings. `./tools/checkpatch.sh -m -g
HEAD~2..HEAD` passes.
Hardware: Waveshare ESP32-S3-RS485-CAN board (ESP32-S3R8, isolated
TJA1051 CAN transceiver, TWAI TX GPIO15 / RX GPIO16) at 500 kbit/s,
connected to a ZLAC8015 servo drive (CANopen node 1). The board ran NuttX
13.0.1 with the same two-line clock fix (13.0.1's `esp32s3_twaiinitialize()`
is identical to master's). The test app reads the bit timing with
`CANIOC_GET_BITTIMING` and the TWAI error counters, then sends expedited SDO
upload requests.
Before (no frames received, every request unacknowledged, the board's CAN
activity LED lit continuously from the drive's retransmissions):
```
nsh> zlac_probe -t can listen 15
zlac_probe: controller at 809 bit/s, 14 tq/bit (tseg1 8, tseg2 5, sjw 1),
sample point 64%
0 ms TWAI rec=199 tec=199 status=0x140DC7 BUS-OFF err-warning last
error: other error while transmitting, in ID 17-13
zlac_probe: 0 frame(s) received in 15 s
15070 ms TWAI rec=199 tec=199 status=0x140DC7 BUS-OFF err-warning last
error: other error while transmitting, in ID 17-13
nsh> zlac_probe -t can scan
zlac_probe: scanning node-ids 1-127 on can (30 ms each)...
zlac_probe: 0 responder(s)
```
(The error counters and status above are the same stale register value,
0x140DC7, read through a gated peripheral; they are not real controller
state.)
After:
```
nsh> zlac_probe -t can
zlac_probe: SDO read 0x200A:00 from node 1
0x200A:00: 1000 (0x03E8, signed 1000, 2 byte(s))
nsh> zlac_probe -t can status
zlac_probe: can, node 1
hall=7 (ERROR) bus=26.14V motor_temp=-40.0C motor_status=0x0000 (stopped)
fault=0x0200 (Hall error)
```
(The Hall error is expected: no motor was connected. The same values read
over the drive's RS485 interface match.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
