Infineon AURIX: How to find a problematic function in a narrow range if AGBT FIFO overflowed?

Error message AGBT FIFO overflow indicates that TriCore’s internal FIFO overflowed, which means that in a short time too many trace messages were written into FIFO. 

The below steps explain in the TC3xx example how to define custom triggers, use an algorithmic approach, halving the range to find one problematic function.

Possible solution

Such bursts of data can be prevented by excluding recording of the code that generates too many trace messages in a short time.

1. Define a custom trigger to exclude the problematic function. 

The custom trigger will generate an event and enable program tracing only when the CPU executes code outside, e.g. 0x800E50E0-0x800E51E0 address span:

1. Open Manual Trigger Configuration | TriCore Y. Refer to winIDEA Help for more information about manual configuration. 

2. Set ptu_trig_0 to 0x800E50E0 <= IP <= 0x800E51E0 in the Trigger section. 

3. Set EVT8 to !ptu_trig_0 in the Event section. 

4. Set ptu_enable to EVT8  in the Action section. 

2.  Find a section of code responsible for overflow messages.

2.1. Search for functions that have strings.

1. Open View | Debug | Symbol Browser.

2. Search for:

• idle
• OS idle task
  
• notask
• idle loop
• invalid_task or
• any other that indicates a code that could execute in tight loop

3. Check the Disassembly Window if such functions are displayed. If you suspect they could be problematic, exclude them from tracing to see if you can get rid of the overflow message.

2.2. Use a bisect algorithm approach.

An algorithm approach enables reducing in each iteration the memory area where the problematic function is and eventually leads to its exact location. See example below:

1. Find 0x800E51E0 using the algorithm approach. The memory map of TC3xx shows that it starts at 0x00000000 and SFRs start at 0xF0000000. This is the starting point. 

You can eliminate most of the address map by focusing only on addresses that your code is linked to; usually, this will be in FLASH memory, which is located between 0x80000000 and 0x90000000 and is mirrored between  0xA0000000 and 0xB0000000. In this example, we'll focus on the whole memory map.

2. Half the range and define the following trigger, which will record record all program executions between address 0x00000000 and 0x80000000 included:

a. Set ptu_trig_0 to 0x00000000 <= IP <= 0x80000000 in the Trigger section. 

b. Set EVT8 to ptu_trig_0 in the Event section. Note that the operator "!" is removed. 

c. Make sure ptu_enable is set to EVT8 in the Action section. 

d. Run the Analyzer. winIDEA doesn't display the overflow error message. That means that the problematic function is in the range between 0x80000000 and 0xF0000000.

3. To confirm the above assumption adjust the trigger to:

a. Set ptu_trig_0 to 0x80000000 <= IP <= 0xF0000000 in the Trigger section. 

b. Make sure EVT8 is set to ptu_trig_0 in the Event section. Note that the operator "!" is removed. 

c. Make sure ptu_enable is set to EVT8  in the Action section. 

d. Run the Analyzer. winIDEA displays the overflow error message. That is an indication the function is in range between 0x80000000 and 0xF0000000.

4. Half the range and limit it between 0x80000000 and 0xC0000000. winIDEA displays the overflow error message.

5. Half the range and limit it between 0x80000000 and 0xA0000000. winIDEA displays the overflow error message.

6. Continue with the following ranges:

a. 0x80000000 and 0x90000000 - overflow error message.

b. 0x80000000 and 0x88000000 - overflow error message.

c. 0x80000000 and 0x84000000 -  overflow error message.

d. Continue by halving the range in each step until you reach a single address or address range.

Usually, a wider range indicates that you have more than one function which generates an overflow. To find two or more ranges to exclude from tracing refer to the topic How to find two or more problematic function in a wider range if AGBT FIFO overflowed?