AURIX™

[User16286]

My current problem is the IfxAsclin_Asc library transmits one character and stops.
From what I can tell, IfxAsclin_Asc_write() puts one character into the TXFIFO
and then relies on the ASCLIN0 TX interrupt handler to send the rest of the bytes.
I have placed a breakpoint on the ASCLIN0 TX interrupt handler and confirmed it
is never called.

I've examined the relevant hardware registers, and here's what I see:

ASCLIN0_TXFIFOCON.INTLEVEL = 15 TXFIFO interrupts if TXFIFO level is <= 15
ASCLIN0_FLAGSENABLE.TFLE = 1 TFL interrupt enabled
ASCLIN0_FLAGS.TFL = 1 Transmit interrupt pending

SRC_ASCLIN0TX.SRE = 1 Service request is enabled
SRC_ASCLIN0TX.SRR = 0 No service request pending
SRC_ASCLIN0TX.TOS = 0 CPU0 service

CPU0_ICR.IE = 1 Interrupts enabled

My interpretation of these values is:

o The ASCLIN0 TX has generated an interrupt.
o The SRC has not received an service request (interrupt) from ASCLIN0.

This doesn't make sense.
What other registers can I check to gain more insight into this problem?

EDIT: I figured it out - bad interaction with Hitec interrupt handler.

Toshi

[User16286]

Next ASCLIN problem:

I'm using the Hitec startup code, and it does not setup the BIV.
Therefore, I need to manually load the BIV.
I'm using this code:

__mtcr(CPU_BIV, (uint32)__int_handler_start);

This generates:

movh d15,0x8020
addi d15,d15,-0x20
...
mtcr 0xfe20,d15

The problem is I can single step the mtcr instruction, but I don't see the value of CPU0_BIV change in the
debugger. The value stays at 0. Yes, the CPU is in supervisor mode (CPU0_PSW.IO = 2).

Anything I should check?

Toshi

[VincentWan]

Hi

Did the code clear CPU ENDINIT bit before accessing register BIV?
Some of AURIX critical registers are ENDINIT protected.

The following registers are ENDINIT protected:
• BTV, BIV, ISP, PMA0, PMA1, PMA2

[User16286]

VincentWan wrote:
Hi

Did the code clear CPU ENDINIT bit before accessing register BIV?
Some of AURIX critical registers are ENDINIT protected.

The following registers are ENDINIT protected:
• BTV, BIV, ISP, PMA0, PMA1, PMA2

Ugh, this isn't mentioned in the architecture manual.
I wrapped it with clear/set of the ENDINIT, and it works.
Thanks.

Toshi

[cwunder]

Ugh, this isn't mentioned in the architecture manual.

Yes it is see "TC_Architecture_vol1_TC161_TCS_TC16P_TC16E.pdf" on page 37

[User16286]

cwunder wrote:
Yes it is see "TC_Architecture_vol1_TC161_TCS_TC16P_TC16E.pdf" on page 37

I have worked on processor architecture and instruction set architectures before, at Renesas and other companies.
Two of my six patents (US 7,412,581 and US 7,877,572) are in the realm of microprocessor architecture.
So I have some experience with processor and instruction set architecture manuals.

In addition, I have programmed in assembly language on multiple processors, including the 6502, 65816, 68000, SH2, SH4, H8/300H, MIPS, x86 16/32/64-bit, etc.
So I also have experience reading instruction set manuals as a user as well.

In my experience, the definition of an instruction in the architecture manual should concisely define its behavior.
For example, an ALU instruction for a CISC architecture typically includes its effect on the bits in the flags register.
If the result of an ALU operation is zero, then the zero flag should be set, etc.
For memory access instructions, such as loads and stores, the behavior for an MMU fault is specified.
So for an instruction such as MTCR, the behavior of the instruction if ENDINIT is set should be specified.
The definition of the MTCR instruction in the TC Architecture manual does not include any mention of ENDINIT.
So I consider this a manual bug.



Toshi

[cwunder]

Hi Toshi,

I don't doubt your experience or skill. I just wish to make the statements below to help clarification.

I personally don't share the same view that MTCR instruction definition is a defect or bug with the documentation. The MTCR and MFCR instructions have nothing to do with the protection scheme it is simply a Core MOV instruction. The CPU ENDINIT is only one part of the many protection schemes used with AURIX (TriCore). With AURIX (TriCore) whenever you intend to make a write access to an SFR you must look up in the manual what are the access rights. The Register Access Modes describe the rights, and I would agree there is manual bug for the TC22/3 user's manuals as this section is missing however it is in the TC27x and TC29x user's manuals.

Here is a partial list Core SFR's and it states BIV needs the CPU ENDINIT protection to be open SYSCON needs the Safety ENDINIT to be open and the PSW doesn't' require either.of these protections.


Access Terms (partial list)


ASCLIN SFR's (partial list)


Best regards
-Chris

[User16286]

cwunder wrote:
Hi Toshi,

I don't doubt your experience or skill. I just wish to make the statements below to help clarification.

I personally don't share the same view that MTCR instruction definition is a defect or bug with the documentation. The MTCR and MFCR instructions have nothing to do with the protection scheme it is simply a Core MOV instruction. The CPU ENDINIT is only one part of the many protection schemes used with AURIX (TriCore). With AURIX (TriCore) whenever you intend to make a write access to an SFR you must look up in the manual what are the access rights. The Register Access Modes describe the rights, and I would agree there is manual bug for the TC22/3 user's manuals as this section is missing however it is in the TC27x and TC29x user's manuals.

Here is a partial list Core SFR's and it states BIV needs the CPU ENDINIT protection to be open SYSCON needs the Safety ENDINIT to be open and the PSW doesn't' require either.of these protections.


Access Terms (partial list)


ASCLIN SFR's (partial list)


Best regards
-Chris

My assertion is the instruction definition in a processor architecture manual should concisely define the behavior of an instruction.
You apparently disagree with this.
Let's agree to disagree on this issue.

Toshi