Parity/CRC error on load

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User16286
Level 4
Level 4
First like received
Trying to use the TC234 ADAS ASCLIN module for serial, and I'm having this problem:

IfxAsclin_setCtsInput(cts->module, (IfxAsclin_CtsInputSelect)cts->select);
0x8001A652 19 EF C8 DF LD.W d15,[a14]-0xB8 <- trap on this instruction
0x8001A656 60 FF MOV.A a15,d15
0x8001A658 48 02 LD.W d2,[a15]0x0
0x8001A65A 19 EF C8 DF LD.W d15,[a14]-0xB8
0x8001A65E 60 FF MOV.A a15,d15
0x8001A660 4C F3 LD.W d15,[a15]0xC
0x8001A662 59 E2 E8 CF ST.W [a14]-0xD8,d2
0x8001A666 59 EF E4 CF ST.W [a14]-0xDC,d15

The trap is class 4, TIN 3 which is a Parity/CRC error.
a14 is 0x70003f40, so the EA of [a14]-0xb8 should be 0x70003e88.
I can view the address in the PLS debugger just fine - the value is 0x8003f850.
If the value was uninitialized (e.g. parity error), it should show up as ???????? in the debugger I believe.
Anybody have any insight?

Toshi
0 Likes
9 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hi Toshi. Class 4 TIN 3 is a DAE (Data Access Asynchronous Error). DEADD will contain the address of the error. The actual instruction that caused the error is probably two or three instructions prior to the trap return address, because the TriCore uses Store Buffers to perform writes in the background. See 6.6.3 Store Buffers on page 228 of tc23x_tc22x_um_v1.1.pdf.
0 Likes
User16286
Level 4
Level 4
First like received
UC_wrangler wrote:
Hi Toshi. Class 4 TIN 3 is a DAE (Data Access Asynchronous Error). DEADD will contain the address of the error. The actual instruction that caused the error is probably two or three instructions prior to the trap return address, because the TriCore uses Store Buffers to perform writes in the background. See 6.6.3 Store Buffers on page 228 of tc23x_tc22x_um_v1.1.pdf.


I think I see it.

IfxAsclin_enableCts(cts->module, TRUE);
0x8001A614 19 EF C8 DF LD.W d15,[a14]-0xB8
0x8001A618 60 FF MOV.A a15,d15
0x8001A61A 4C F0 LD.W d15,[a15]0x0
0x8001A61C 59 EF F0 CF ST.W [a14]-0xD0,d15
0x8001A620 82 1F MOV d15,0x1
0x8001A622 E9 EF EF CF ST.B [a14]-0xD1,d15

DEADD is 0xf0000604, and a15 is 0xf0000600, so it may be the load instruction.
it's off by four bytes, though.

Toshi
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
TMorita wrote:
Erm. I don't think you understand the problem.
This problem can be replicated by single-stepping the instructions in the PLS debugger.
So there is some sort of debugger kernel running on the target.
Therefore, the few instructions before this instruction would be in the debugger kernel.
So by your logic, the problem is in the debugger kernel, which seems unlikely.
Toshi

No debugger kernel is required. The TriCore architecture has support for single stepping within the Core Debug Controller:

TC_Architecture_vol1_TC161_TCS_TC16P_TC16E.pdf
12 Core Debug Controller (CDC)
12.1 Run Control Features
Features
• Single-Step support in hardware.
0 Likes
User16286
Level 4
Level 4
First like received
It's trapping on an access to an ASCLIN register.
I just checked, and the TC234LA does have the LIN module.
So this is weird.

Toshi
0 Likes
User16286
Level 4
Level 4
First like received
TMorita wrote:
It's trapping on an access to an ASCLIN register.
I just checked, and the TC234LA does have the LIN module.
So this is weird.

Toshi


It looks like it's access protected, and for some reason my version of iLLD doesn't unlock the register before accesssing...
Sigh.

Toshi
0 Likes
User16286
Level 4
Level 4
First like received
Looks like it's already unlocked, but trapping anyway.

ASCLIN0_ACCEN0 = 0xffffffff
ASCLIN1_ACCEN0 = 0xffffffff

Toshi
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Have you enabled the peripheral via ASCLIN0_CLC=0 (usually handled by IfxAsclin_setEnableModuleRequest)? If not, none of the ASCLIN registers (except CLC) will be visible in the debugger, or writable by the application.
0 Likes
User16286
Level 4
Level 4
First like received
UC_wrangler wrote:
Have you enabled the peripheral via ASCLIN0_CLC=0 (usually handled by IfxAsclin_setEnableModuleRequest)? If not, none of the ASCLIN registers (except CLC) will be visible in the debugger, or writable by the application.


o I am using iLLD, so I shouldn't have to enable it manually.
o I am calling IfxAsclin_Asc_initModule(), and this calls IfxAsclin_enableModule(), which calls IfxAsclin_setEnableModuleRequest().
o I can see ASCLIN0_CLC in the PLS debugger, and the value is 0x00000003.
This is EDIS = 0, DISS = 1, and DISR = 1.

Toshi
0 Likes
User16286
Level 4
Level 4
First like received
I've found where it's crashing, and it's definitely an access to the ASCLIN IOCR.

FX_INLINE void IfxAsclin_enableCts(Ifx_ASCLIN *asclin, boolean enable)
{
asclin->IOCR.B.CTSEN = enable ? 1 : 0;
0x8001A626 39 EF EF CF LD.BU d15,[a14]-0xD1
0x8001A62A 8B 0F 20 F2 NE d15,d15,0x0
0x8001A62E 8F FF 0F 21 AND d2,d15,0xFF
0x8001A632 19 EF F0 CF LD.W d15,[a14]-0xD0
0x8001A636 8F 12 00 21 AND d2,d2,0x1
0x8001A63A 8F D2 01 20 SH d2,d2,0x1D
0x8001A63E 60 FF MOV.A a15,d15
0x8001A640 48 13 LD.W d3,[a15]0x4
0x8001A642 7B 00 00 4E MOVH d4,0xE000
0x8001A646 C2 F4 ADD d4,-0x1
0x8001A648 26 43 AND d3,d4
0x8001A64A A6 32 OR d2,d3
0x8001A64C 02 23 MOV d3,d2
0x8001A64E 60 FF MOV.A a15,d15
0x8001A650 68 13 ST.W [a15]0x4,d3 <- here


A15 = 0xf0000600, so A15 + 4 = 0xf0000604, which is the value I see in CPU0_DEADD.

So apparently the trap is occurring when attempting to write to the ASCLIN IOCR.

Toshi
0 Likes