ETHERNET for Aurix TC234

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

cross mob
User16330
Level 2
Level 2
Hi,
Thanks in advance.

I have posted lots of question regarding implementation of ethernet communication on TC234 of Aurix. Here is the new question hope somebody will help me out.

I am running the ethernet demo code in loopback mode, the problem is its getting stuck in a trap and the trap is called "CPU TRAP BUS ERROR" its getting stuck in this trap,

the code after which this trap is generated is "pin-mode" select function.


please somebody help.
0 Likes
7 Replies
User13290
Level 5
Level 5
First like received First solution authored
Hi Vivek,

vivekrsingh20 wrote:
Hi,
Thanks in advance.

I have posted lots of question regarding implementation of ethernet communication on TC234 of Aurix. Here is the new question hope somebody will help me out.

I am running the ethernet demo code in loopback mode, the problem is its getting stuck in a trap and the trap is called "CPU TRAP BUS ERROR" its getting stuck in this trap,

the code after which this trap is generated is "pin-mode" select function.


please somebody help.


When you receive a bus trap then you must start by tracing down the offending instruction that triggers it. I always use the stacktrace window for that.

The stacktrace shows the program flow changes of your program and marks out the path the leads up to your trap. Once you have an idea of the program flow you can strategically set some breakpoints, close to the point where you think the trap is being triggered. From that point you need to start stepping your program on assembly level and home in on the offending instruction. Once you've found it, you're not that far away from discovering what has happened.

Just from the top of my head a bus error can occur for a couple of reasons:


  • Accessing memory that doesn't exist.
  • Accessing memory using the wrong alignment.
  • Executing code from non-existent memory.

There maybe more, but these will give you an idea what to look for. When you have found the instruction you need to step up to it but not execute it. Next you open up the register window to review the state of the registers that are about to be used in the offending instruction. You can now check what memory is about to be accessed and whether it is properly aligned or not. And you should be able to tell which offence is about to be committed.

Once you know the cause the next step is to try and rhyme it with your application memory map. For example, you may find that your linker script defined a memory which is too large for the architecture you're using. So it may consequently have located stuff in memory that doesn't exist (=trap). Or you may find you declared a semaphore that was located at a half-word boundary. When you subsequently try to access it with for example a swap instruction you'll be in for a treat as well (=trap) because the swap instruction requires word-alignment. Or suppose the program for some reason destroys the return address register then a ret instruction might return to an address that doesn't exist (=trap).

Depending on the cause you may subsequently start pointing fingers. But since that has a negative connotation I prefer to say that you've arrived at a juncture where you can start working towards a solution. Here's a couple of scenario's that relate to the aforementioned bus errors.

A memory that was defined too large denotes a user error. You'll need to correct that in your linker script. An alignment error can either be a user error or a compiler error. If you use the TASKING compiler then integers may be half-word aligned if you have not specifically indicated that you want to be EABI compliant. So you must then explicitly use the __align() attribute to force off word alignment if variables are going to be accessed with specific instructions that require so. Neglecting to do so would then denote a user error. However a compiler can theoretically also use half-word alignment despite EABI compliance and then it signifies a bug. If a return address register gets scrambled then again it can be either. The point is you don't know until you've done all the work.

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes
User16330
Level 2
Level 2
HIGHTEC.henk-piet.glas wrote:
Hi Vivek,



When you receive a bus trap then you must start by tracing down the offending instruction that triggers it. I always use the stacktrace window for that.

The stacktrace shows the program flow changes of your program and marks out the path the leads up to your trap. Once you have an idea of the program flow you can strategically set some breakpoints, close to the point where you think the trap is being triggered. From that point you need to start stepping your program on assembly level and home in on the offending instruction. Once you've found it, you're not that far away from discovering what has happened.

Just from the top of my head a bus error can occur for a couple of reasons:


  • Accessing memory that doesn't exist.
  • Accessing memory using the wrong alignment.
  • Executing code from non-existent memory.

There maybe more, but these will give you an idea what to look for. When you have found the instruction you need to step up to it but not execute it. Next you open up the register window to review the state of the registers that are about to be used in the offending instruction. You can now check what memory is about to be accessed and whether it is properly aligned or not. And you should be able to tell which offence is about to be committed.

Once you know the cause the next step is to try and rhyme it with your application memory map. For example, you may find that your linker script defined a memory which is too large for the architecture you're using. So it may consequently have located stuff in memory that doesn't exist (=trap). Or you may find you declared a semaphore that was located at a half-word boundary. When you subsequently try to access it with for example a swap instruction you'll be in for a treat as well (=trap) because the swap instruction requires word-alignment. Or suppose the program for some reason destroys the return address register then a ret instruction might return to an address that doesn't exist (=trap).

Depending on the cause you may subsequently start pointing fingers. But since that has a negative connotation I prefer to say that you've arrived at a juncture where you can start working towards a solution. Here's a couple of scenario's that relate to the aforementioned bus errors.

A memory that was defined too large denotes a user error. You'll need to correct that in your linker script. An alignment error can either be a user error or a compiler error. If you use the TASKING compiler then integers may be half-word aligned if you have not specifically indicated that you want to be EABI compliant. So you must then explicitly use the __align() attribute to force off word alignment if variables are going to be accessed with specific instructions that require so. Neglecting to do so would then denote a user error. However a compiler can theoretically also use half-word alignment despite EABI compliance and then it signifies a bug. If a return address register gets scrambled then again it can be either. The point is you don't know until you've done all the work.

Best regards,

Henk-Piet Glas
Principal Technical Specialist


Thankyou a lot.

I am providing you with my code snippets,
IFX_INLINE void IfxPort_setPinModeInput(Ifx_P *port, uint8 pinIndex, IfxPort_InputMode mode)
{
IfxPort_setPinMode(port, pinIndex, (IfxPort_Mode)mode);
0x80001B3C: 82 05 MOV d5,0x0

0x80001B3E: 68 02 ST.W [a15]0x0,d2

0x80001B40: 48 02 LD.W d2,[a15]0x0

0x80001B42: 19 23 0C 00 LD.W d3,[a2]0xC

0x80001B46: 60 92 MOV.A a2,d9

0x80001B48: 37 32 02 23 INSERT d2,d2,d3,0x6,0x2

0x80001B4C: 68 02 ST.W [a15]0x0,d2

0x80001B4E: 48 02 LD.W d2,[a15]0x0

0x80001B50: 19 23 0C 00 LD.W d3,[a2]0xC

0x80001B54: 60 82 MOV.A a2,d8

0x80001B56: 37 32 02 24 INSERT d2,d2,d3,0x8,0x2

0x80001B5A: 68 02 ST.W [a15]0x0,d2

0x80001B5C: 48 02 LD.W d2,[a15]0x0

0x80001B5E: 19 23 0C 00 LD.W d3,[a2]0xC

0x80001B62: 60 F2 MOV.A a2,d15

0x80001B64: 37 32 02 25 INSERT d2,d2,d3,0xA,0x2

0x80001B68: 68 02 ST.W [a15]0x0,d2

0x80001B6A: 48 02 LD.W d2,[a15]0x0

0x80001B6C: 19 23 0C 00 LD.W d3,[a2]0xC

0x80001B70: 60 B2 MOV.A a2,d11

0x80001B72: 37 32 02 26 INSERT d2,d2,d3,0xC,0x2

0x80001B76: 68 02 ST.W [a15]0x0,d2

0x80001B78: 48 02 LD.W d2,[a15]0x0

0x80001B7A: 19 E3 0C 00 LD.W d3,[a14]0xC

0x80001B7E: 37 32 02 27 INSERT d2,d2,d3,0xE,0x2

0x80001B82: 68 02 ST.W [a15]0x0,d2

0x80001B84: 19 D3 0C 00 LD.W d3,[a13]0xC

0x80001B88: 48 02 LD.W d2,[a15]0x0

0x80001B8A: 37 32 02 28 INSERT d2,d2,d3,0x10,0x2

0x80001B8E: 68 02 ST.W [a15]0x0,d2

0x80001B90: 48 02 LD.W d2,[a15]0x0

0x80001B92: 19 C3 0C 00 LD.W d3,[a12]0xC

0x80001B96: 37 32 02 29 INSERT d2,d2,d3,0x12,0x2

0x80001B9A: 68 02 ST.W [a15]0x0,d2

0x80001B9C: 19 23 0C 00 LD.W d3,[a2]0xC

0x80001BA0: 48 02 LD.W d2,[a15]0x0

0x80001BA2: 37 32 02 2A INSERT d2,d2,d3,0x14,0x2

0x80001BA6: 68 02 ST.W [a15]0x0,d2

0x80001BA8: 60 DF MOV.A a15,d13

0x80001BAA: C8 14 LD.A a4,[a15]0x4

0x80001BAC: 08 84 LD.BU d4,[a15]0x8

0x80001BAE: 60 BF MOV.A a15,d11

0x80001BB0: 6D 00 A3 06 CALL IfxPort_setPinMode (0x800028F6)

> 0x80001D9E: 82 05 MOV d5,0x0

> 0x80001DA0: 4C F3 LD.W d15,[a15]0xC

> 0x80001DA2: 91 20 00 FF MOVH.A a15,0xF002

> 0x80001DA6: D9 FF 08 0D LEA a15,[a15]-0x2FF8

> 0x80001DAA: 48 02 LD.W d2,[a15]0x0

> 0x80001DAC: 37 F2 02 F0 INSERT d15,d2,d15,0x0,0x2


3417.attach

What I found is that in address 0x80001DAA the bus error is occuring and its of CLASS 4 AND TIN 2.
the instruction LD.W D2,[A15] in 0x80001DAA is trying to fetch a data from memory location 0xF001D008, AND THIS MEMORY location is having no data and represents DSPR memory range.

The error according to me is "DATA LOAD FROM BUS CAUSING ERROR" this I found from register DSTR and DEADD.



Please help me out, am stuck in this for more than 1 month, please do help.

thanks and regard
0 Likes
User13290
Level 5
Level 5
First like received First solution authored
Hi Vivek,

vivekrsingh20 wrote:
Thank you a lot. Please help me out, am stuck in this for more than 1 month, please do help.


I was able to reproduce using this example:

#include 

int main(void) {
return ETH_GPCTL.U;
}

Turns out, after studying the familiy manual and datasheets, that this is caused because some TC23x derivatives do not have the ethernet module. The family manual states that the registers are still accessible but functionality cannot be guaranteed. The way to check if the same applies to you is by checking the SHU_CHIPID register in your peripheral register window of your debugger. This will give you a specific value, in my case 0x44463142. This you can subsequently cross-reference against TC23x_DS_Add_v2.1.pdf available from MyICP. The given datasheet will then tell which specific device that is and if the ETH module is incorporated. As expected, in my case it isn't. I'm guessing the same for you.

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes
User16330
Level 2
Level 2
HIGHTEC.henk-piet.glas wrote:
Hi Vivek,



I was able to reproduce using this example:

#include 

int main(void) {
return ETH_GPCTL.U;
}

Turns out, after studying the familiy manual and datasheets, that this is caused because some TC23x derivatives do not have the ethernet module. The family manual states that the registers are still accessible but functionality cannot be guaranteed. The way to check if the same applies to you is by checking the SHU_CHIPID register in your peripheral register window of your debugger. This will give you a specific value, in my case 0x44463142. This you can subsequently cross-reference against TC23x_DS_Add_v2.1.pdf available from MyICP. The given datasheet will then tell which specific device that is and if the ETH module is incorporated. As expected, in my case it isn't. I'm guessing the same for you.

Best regards,

Henk-Piet Glas
Principal Technical Specialist



Thanks a lot for your help,
My SCU_CHIPID IS SAME AS YOURS 44463142 and as said by you it doesnt have an ethernet compatibility.
Now I can say there is no problem with my code, its the hardware that doesnt support it.

Thanks a lot for helping, otherwise i would have been stuck in getting ethernet up and ready in this TC234

THANKS A LOT
Regards.
0 Likes
User13290
Level 5
Level 5
First like received First solution authored
Hi Vivek,

vivekrsingh20 wrote:
Thanks a lot for your help,
My SCU_CHIPID IS SAME AS YOURS 44463142 and as said by you it doesnt have an ethernet compatibility.
Now I can say there is no problem with my code, its the hardware that doesnt support it.

Thanks a lot for helping, otherwise i would have been stuck in getting ethernet up and ready in this TC234

THANKS A LOT
Regards.


Happy to help and good to read you've confirmed the above findings. Happy developing!

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes
User16330
Level 2
Level 2
HIGHTEC.henk-piet.glas wrote:
Hi Vivek,



Happy to help and good to read you've confirmed the above findings. Happy developing!

Best regards,

Henk-Piet Glas
Principal Technical Specialist


Hello Henk,
Sorry to disturb you again, but I have one more question, according to your previous replies the
ChipID doesn't support ethernet connectivity.

what if I buy the TC23x of CHIPID 4443 3941 or OF 44473941, according to data sheet these
variants support Ethernet connectivity.
So I need your approval, or can you assure me that TC234 with this CHIPID the ethernet communication can be enabled easily. 3420.attach

Thanks and Regards
0 Likes
User13290
Level 5
Level 5
First like received First solution authored
Hi Vivek,

vivekrsingh20 wrote:

So I need your approval, or can you assure me that TC234 with this CHIPID the ethernet communication can be enabled easily.


I cannot make a call on this. You'll have to discuss this with your local Infineon contact. Before you do, I recommend first taking a look at TC23x_AB_Errata_Sheet_v1_6_062_18.pdf to see if there are any functional deviations that you may want to discuss as well.

Best regards,

Henk-Piet Glas
Principal Technical Specialist Embedded Software
0 Likes