传感器论坛 - 最近的话题

IWRL1432: 同一组adc数据，用hwa做fft的结果与matlab fft结果不一致。

user5977184 — Thu, 27 Aug 2026 07:46:25 GMT

Part Number: IWRL1432

同一组adc数据，红色是matlab fft DB图，蓝色是HWA的fft DB图。

做的是4096点fft。调节scale与butterflyScaling，可以得到以下两种。第一种是大部分曲线是重合的，但是个别处差的挺多。第二种是不重合，但曲线趋势一致。哪种曲线更好呢？

RE: IWRL1432: 同一组adc数据，用hwa做fft的结果与matlab fft结果不一致。

Eirwen — Thu, 27 Aug 2026 08:54:50 GMT

已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

AWR1443: ABOUT AWR 1443 REGS

tang tang — Wed, 26 Aug 2026 06:05:23 GMT

Part Number: AWR1443

Dear Engineer,

I have reviewed the AWR1443 datasheet prior to configuring data transmission for the CBUFF module. Two registers, STAT_CBUFF_REG0 and STAT_CBUFF_REG1,are used for interrupt status storage. STAT_CBUFF_REG0 has its corresponding clear register CLR_CBUFF_REG0, while no dedicated CLR_CBUFF_REG1 is provided for STAT_CBUFF_REG1, I would like to know how to clear the status bits inside STAT_CBUFF_REG1.

I have also downloaded the mmWave‑SDK firmware package. I checked the CBUFF register definition files within the SDK, and there is no CLR_CBUFF_REG1 defined there either.

RE: AWR1443: ABOUT AWR 1443 REGS

Alice — Thu, 27 Aug 2026 04:58:40 GMT

您好，

设计手册上没有更新，在AWR18xx/16xx/14xx Technical Reference Manual (Rev. E) “15.2.5.2 CBUFF Error Interrupt (DSS_CBUFF_ERR_IRQ)” 中有提到CLR_CBUFF_REG1。

CLR_CBUFF_REG1对应的偏移地址是210h。

RE: AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop

Links — Wed, 26 Aug 2026 10:06:47 GMT

Hi，

Please check the following link

(+) AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop - 传感器论坛 - 传感器 - E2E™ 设计支持

AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop

hui lu — Fri, 21 Aug 2026 10:48:21 GMT

Part Number: AWR2944

Part: AWR2944
SDK / MCAL version: 04.07.01.03
IP: Bosch M_CAN (MCAN peripheral)

=== 1. Setup ===

We are running a UDS 0x11 0x01 (ECU reset) stress test on AWR2944:
- Two MCAN controllers are active:
- MCAN1 @ 0x02040000 ("public" CAN, connected to the tester which ACKs)
- MCAN2 @ 0x03040000 ("private" CAN, no other node connected on this bench — dangling bus, no ACK)
- Auto retransmission is ENABLED (CCCR.DAR = 0).
- The application transmits periodic frames on the private CAN from early boot
(unconditionally, ~20 ms period).
- Consequence on the dangling bus: the first private-CAN frame fails with no ACK
and enters permanent retransmission; the controller goes error passive
(PSR: LEC=7 "no ACK", EP=1, BO=0) and TXBRP stays 0x1 indefinitely.

The MCAL Can driver's Can_mcanStop() performs, in this order:

1. MCAN_setOpMode(base, MCAN_OPERATION_MODE_SW_INIT); /* set CCCR.INIT */
2. poll MCAN_getOpMode() until INIT is reached;
3. read TXBRP, and for each pending buffer:
MCAN_txBufCancellationReq(base, bufIdx); /* write TXBCR bit */
poll until (TXBCF & bit) == bit; /* <-- wait loop */

On each ECU reset (warm reset), the next boot calls Can_mcanStop() again on both
controllers (communication bring-up does STOPPED -> STARTED). So every reset
cycle exercises this cancel path while the private-CAN frame is stuck in
retransmission.

=== 2. Phenomenon ===

Out of ~3000 reset cycles, ~40 runs (~1.3%) hang in the TXBCF wait loop of
Can_mcanStop() on the private CAN (0x03040000). After the hang the ECU never
finishes booting and the public CAN stays silent (the tester declares a failure
after 10 s of bus silence).

Paired logs — identical register state at stop entry, opposite outcomes:

FAIL (hang):
[CanStop ENTRY] base=0x3040000 TXBRP=0x1 TXBTO=0x0 TXBCF=0x0 LEC=7 BO=0 EP=1
cancel request for buffer 0 issued (TXBCR bit 0 written while in INIT mode)
-> TXBCF never sets, TXBRP never clears, loop spins forever

PASS (same bench, seconds later):
[CanStop ENTRY] base=0x3040000 TXBRP=0x1 TXBTO=0x0 TXBCF=0x0 LEC=7 BO=0 EP=1
cancel request for buffer 0 issued (TXBCR bit 0 written while in INIT mode)
-> TXBRP=0x0, TXBCF=0x1: cancellation completes immediately

The only difference between the two runs is the (invisible) internal state of
the TX buffer / message handler at the moment TXBCR is written.

=== 3. Our analysis (please confirm) ===

Per the M_CAN documentation, cancellation of a Tx buffer is DEFERRED until the
ongoing transmission attempt ends if the cancellation request hits a buffer that
is currently being transmitted. Setting CCCR.INIT freezes the CAN protocol
engine, so a transmission attempt interrupted by INIT never "ends".

Therefore we believe:
- If TXBCR is written while the buffer is merely PENDING ( arbitration not yet
won / attempt not started), the cancel is served even in INIT mode — matches
our PASS log (INIT clearly does not freeze the buffer manager itself).
- If TXBCR is written while the buffer is MID-TRANSMISSION-ATTEMPT, the cancel
is deferred "until the attempt ends", but INIT has frozen the protocol engine
so the attempt can never end -> TXBCF never sets -> indefinite wait.
- On a bus with a healthy ACKer this window is microseconds wide (rare hit);
on our no-ACK bus with auto-retransmission the controller is essentially
always inside a retransmission attempt, so the stop path faces this state
every single boot.

=== 4. Questions ===

Q1. Can you confirm the M_CAN behavior on AWR2944: after CCCR.INIT = 1, is a
cancellation request (TXBCR) for a buffer whose transmission attempt was
interrupted by INIT ever served? Is there any condition under which TXBCF
will set in this state, or is it a permanent deadlock?

Q2. What is TI's recommended sequence to stop/disable MCAN when Tx buffers may
be active — should all pending transmissions be cancelled (TXBCR + wait for
TXBCF, with a timeout) BEFORE setting CCCR.INIT? Is there an app note or
newer MCAL drop that reorders Can_mcanStop this way?

Q3. In INIT mode with auto-retransmission enabled and no ACK on the bus, is the
intended recovery path a peripheral reset (MCAN module reset via CTRL_MMR /
TopRCM), since software cannot force the deferred cancellation to complete?

Q4. Is this a known limitation/erratum of the M_CAN integration, and is there an
E2E thread or TI MCAL release note that documents the TXBCR/TXBCF/TXBRP
interplay with CCCR.INIT?

Any guidance is appreciated. We can provide the full paired logs and the exact
register readouts on request.

AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop

hui lu — Fri, 21 Aug 2026 10:47:34 GMT

Part Number: AWR2944

Part: AWR2944
SDK / MCAL version: 04.07.01.03
IP: Bosch M_CAN (MCAN peripheral)

=== 1. Setup ===

The MCAL Can driver's Can_mcanStop() performs, in this order:

=== 2. Phenomenon ===

Paired logs — identical register state at stop entry, opposite outcomes:

The only difference between the two runs is the (invisible) internal state of
the TX buffer / message handler at the moment TXBCR is written.

=== 3. Our analysis (please confirm) ===

=== 4. Questions ===

Q4. Is this a known limitation/erratum of the M_CAN integration, and is there an
E2E thread or TI MCAL release note that documents the TXBCR/TXBCF/TXBRP
interplay with CCCR.INIT?

Any guidance is appreciated. We can provide the full paired logs and the exact
register readouts on request.

RE: AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop

hui lu — Wed, 26 Aug 2026 09:44:04 GMT

Thanks for your reply. I'll check on this and try the method you mentioned

RE: AWR1443: ABOUT AWR 1443 REGS

Alice — Wed, 26 Aug 2026 08:05:31 GMT

您好，
已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

RE: AWR2944: AWR2944 MCAN: TX buffer cancellation (TXBCR/TXBCF) never completes when CCCR.INIT is set while a transmission attempt is in progress — ECU hangs in Can_mcanStop

Ken Zhang — Wed, 26 Aug 2026 03:39:49 GMT

AWR2944 MCAN fully follows the behavior described in BOSCH MCAN_USER_MANUAL

mcan_users_manual_v331.pdf

Pls refer to above user guide to acquire more information.

Also, I would suggest completion of current on-going frame and disable all the MCAN interrupts before any warm reset of AWR2944 or MCAN IP.

Many customers suffered from this issue because they failed to execute above advice when jumping from SBL to APP.(which is similar to warm reset of device or MCAN IP)

Thanks

Ken

AWR1843AOPEVM: AWR1843AOPEVM 连接失败

longlong ma — Mon, 24 Aug 2026 12:34:42 GMT

Part Number: AWR1843AOPEVM

AWR1843AOPEVM 通过 mmWave Studio 和 DCA1000EVM 连接失败

我确认了我的设置和网络服务器设置都与与用户手册中的保持一致,PC也能正确读取设备串口,但是就是无法在 mmWave Studio 中连接
这个是错误代码!
[20:09:29] [RadarAPI]: ar1.Calling_IsConnected()
[20:09:29] [RadarAPI]: ar1.SaveSettings('C:\Users\think\AppData\Roaming\RSTD\ar1gui.ini')
[20:18:57] [RadarAPI]: Opening Gpio Control Port()
[20:18:57] [RadarAPI]: Status: Passed
[20:18:58] [RadarAPI]: Opening Board Control Port()
[20:18:58] [RadarAPI]: Status: Passed
[20:18:59] [RadarAPI]: ar1.FullReset()
[20:18:59] [RadarAPI]: Status: Passed
[20:19:00] [RadarAPI]: Closing Board Control Port()
[20:19:00] [RadarAPI]: Status: Passed
[20:19:00] [RadarAPI]: Closing Gpio Control Port()
[20:19:00] [RadarAPI]: Status: Passed
[20:19:00] [RadarAPI]: ar1.SOPControl(2)
[20:19:00] [RadarAPI]: Status: Passed
[20:19:01] [RadarAPI]: ar1.Connect(99,115200,1000)
[20:19:03] [RadarAPI]: Error: Connection failed: Calling_ConnectTarget returned 3
[20:19:03] [RadarAPI]: ar1.Calling_IsConnected()
[20:19:03] [RadarAPI]: ar1.SaveSettings('C:\Users\think\AppData\Roaming\RSTD\ar1gui.ini')