Migration from XMC4500 to XMC4700

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

cross mob
User9718
Level 1
Level 1
Hi Infineon Community and Infineon Staff

We have a well working application with the Infineon XMC4500 Step AC for about one year now.
Because our application is very memory intensive we use the EBU to have external RAM and also we have an external NAND Flash we use with a Filesystem.
We also use the Ethernet Port and USB Host.
Besides this we use 2 USIC Channels in SPI Mode and 3 USIC Channels in UART Mode, the RTC and 3 CAN Nodes with various Message Objects.
For Memory Transfer to the NAND Flash and Datatransfer over SPI we use the GPDMA of the XMC4500.

We now want to port our software Project onto the XMC4700 Step AA because it has more internal RAM and more internal FLASH.
We checked two main differences between XMC500 and XMC4700:
1. Memory Map of internal RAM is different and not compatible (PSRAM and DSRAM), so we changed the Linker Configuration
2. CAN Initialisation is different.

With this two changes the software which works perfectly on the XMC4500 step AC works also on the XMC4500.
But there is one difference:
Sporadically we get Bus Error Traps during DMA Transfers and we can't find the reason for it.

There are no such traps on the XMC4500 with the same Software. We checked for stack overflows and overwriting array boundaries but there is no such problem.

The clock System is configured like on the XMC4500 with fpll = 120 MHz and fsys = 120 MHz. The Clock Konfiguration is checked and is the same.
The EBU Timing is also verified on both CPUs.

Is there any other difference in the two CPUs I don't know about ?

Is there anybody from Infineon staff who can help me with this issue ?

Thanks for your help

Ingo
0 Likes
16 Replies
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

There is no difference in the core, both use a CORTEX-M4F.

Could you add the following code to your main.c?

void __HardFault_Handler(uint32_t args[])
{
volatile uint32_t stacked_r0 ;
volatile uint32_t stacked_r1 ;
volatile uint32_t stacked_r2 ;
volatile uint32_t stacked_r3 ;
volatile uint32_t stacked_r12 ;
volatile uint32_t stacked_lr ;
volatile uint32_t stacked_pc ;
volatile uint32_t stacked_psr ;
volatile unsigned long _CFSR ;
volatile unsigned long _HFSR ;
volatile unsigned long _DFSR ;
volatile unsigned long _AFSR ;
volatile unsigned long _BFAR ;
volatile unsigned long _MMAR ;

stacked_r0 = ((uint32_t)args[0]) ;
stacked_r1 = ((uint32_t)args[1]) ;
stacked_r2 = ((uint32_t)args[2]) ;
stacked_r3 = ((uint32_t)args[3]) ;
stacked_r12 = ((uint32_t)args[4]) ;
stacked_lr = ((uint32_t)args[5]) ;
stacked_pc = ((uint32_t)args[6]) ;
stacked_psr = ((uint32_t)args[7]) ;

// Configurable Fault Status Register
// Consists of MMSR, BFSR and UFSR
_CFSR = (*((volatile unsigned long *)(0xE000ED28))) ;

// Hard Fault Status Register
_HFSR = (*((volatile unsigned long *)(0xE000ED2C))) ;

// Debug Fault Status Register
_DFSR = (*((volatile unsigned long *)(0xE000ED30))) ;

// Auxiliary Fault Status Register
_AFSR = (*((volatile unsigned long *)(0xE000ED3C))) ;

// Read the Fault Address Registers. These may not contain valid values.
// Check BFARVALID/MMARVALID to see if they are valid values
// MemManage Fault Address Register
_MMAR = (*((volatile unsigned long *)(0xE000ED34))) ;
// Bus Fault Address Register
_BFAR = (*((volatile unsigned long *)(0xE000ED38))) ;

__asm("BKPT 0\n") ; // Break into the debugger

}

__attribute__((naked)) void HardFault_Handler(void)
{
__asm(" TST LR, #4 \n"
" ITE EQ \n"
" MRSEQ R0, MSP \n"
" MRSNE R0, PSP \n"
" B __HardFault_Handler\n");
}


Please rerun your application, now when the exception occurs with the debugger connected the execution of the program will stop at __HardFault_Handler function.
Once here please report the value of all local variables belonging to __HardFault_Handler function.

Analyzing the values of the these variables can help us to track back the reason for the exception.

Regards,
Jesus
0 Likes
User9718
Level 1
Level 1
Ok, we will do this immediately
0 Likes
User9718
Level 1
Level 1
Here are the Infos:

stacked_r0 = 0x20000084;
stacked_r1 = 0x00000001;
stacked_r2 = 0x20000084;
stacked_r3 = 0x0000403E;
stacked_r12 = 0x080238C3;
stacked_lr = 0x080214C9;
stacked_pc = 0x08021154;
stacked_psr = 0x0100000F;
_CFSR = 0x00008200;
_HFSR = 0x00000000;
_DFSR = 0x00000000;
_AFSR = 0x00000000;
_BFAR = 0x08021164;
_MMAR = 0x08021164;

_BFAR points to rt_put_rdy_first() from CMSIS RTOS Lib which is probably called from SysTick_Handler().

Here the corresponding output from the MAP-File:
0x08021152 0x00000002 PAD
0x08021154 0x00000014 Code RO 47261 i.rt_put_rdy_first RTX_CM4_IFX.lib(rt_list.o)
0x08021168 0x00000034 Code RO 47262 i.rt_resort_prio RTX_CM4_IFX.lib(rt_list.o)
0x0802119c 0x00000010 Code RO 47692 i.rt_ret_regs RTX_CM4_IFX.lib(hal_cm.o)



2251.attach

In this try the Trap is released while in SysTick_Handler.
If we apply minor changes to the project the trap address changes.
The only common we found is that the traps are released during DMA Transfers.
In this case we have DMA Transfers between an USIC in SPI Mode and external RAM Memory.
The traps are sporadically. (We have about 1 Trap during 100 DMA Transfers).
The Transfers are Single Block Transfers with 4096 Byte per Transfer.
We do not encounter any Traps when the Transfer is between USIC in SPI Mode and internal RAM Memory.
The Clock Configuration (fcpu, fpll, febu,..) are the same as on XMC4500 (fcpu,fpll=120MHz, febu=120MHz).
Ebu Configuration is the same as in XMC4500.

I can give you further Infos about Clock Configuration, EBU Configuration and PCB and the External Memories if you want.
The same PCB works fine with XMC4500

If you want any further information please let me know
0 Likes
lock attach
Attachments are accessible only for community members.
User9718
Level 1
Level 1
Hi Jesus

We double checked the System Clocks:
We use fpll = 120 MHz, fsys120MHz, pllUsb=192MHz and fusb48Mhz.
We see no differences in the Clocks between XMC4500 and the XMC4700.
(see XMC4500 CPU System Clocks.pdf).

We also double checked the EBU Timing on XMC4500 and XMC4700 and see no differences.
We use fEBU = fsys = fcpu = 120 MHz.
The Timinig is equal between the two contollers.
(See TAS400CpuEbuTm4500vs4700_2016-08-12_edTi.pdf)
Both PCBs are equal (except one has the XMC4500 and the other one the XMC4700).
We have 2 external RAM, one external NAND Flash and one external NOR Flash.

Our Main Software Project and also some Test Projects work on the PCB with the XMC4500. (We use the uVision 5 from ARM/Keil)
All these Projects get above mentioned traps during DMA Transfers from/to the external RAM/Nand Flash/Nor Flash on the PCB with the XMC4700.
We do not get any traps with DMA Transfers to internal RAM on the XMC4700.

Is there a possibility that you can check our info, or is there a way you can help us to check on our PCB if there is maybe a problem with the Step AA Processors.

We wouls be thankful for all infos/suggestions/options you can give us.

Thank you
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Could you tell me what is the code at 0x080214C9?
Could you check if any of the memory arrays involved in the DMA transfer cross memory borders, i.e. from PSRAM to DSRAM1 or DSRAM1 to DSRAM2?

Regards,
Jesus
0 Likes
User9718
Level 1
Level 1
The code at 0x080214C9 belongs to
i.rt_systick RTX_CM4_IFX.lib(rt_system.o)
which is called from the SysTick_Handler.

The project is reduced to only 2 tasks:
- Main Task - which is working on the DMA-Transfers in an endless loop
- Idle Task - which is doing nothing

The DMA transfers are always reading from the SPI Bus to the same memory range in external SRAM (0x681E0000 ... 0x681E0000 + 0x20000 Byte which are read in 32 blocks á 0x1000 Byte).

The same project runs on XMC4500 without problems.


Regards
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

When the fault occurs, could you check the value of the DMA raw error interrupt status?
Is it possible for you to post a minimal program showing the error?

Regards,
Jesus
0 Likes
lock attach
Attachments are accessible only for community members.
User9718
Level 1
Level 1
Hello Jesus

Thanks for your answer.
As you requested I attached a PDF with another detailed problem description and a zip File with a minimal program.
As far as I remember we checked for DMA Errors and there are no DMA Errors. So I think DMA Error Raw Interrupt Status Bit was 0 for all Channels.
But we can double check that.
Jesus, can you please check the attached project and tell me your thoughts about it.
Thank you

Ingo
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi Ingo,

I will check your project and keep you updated.

Regards,
Jesus
0 Likes
User9718
Level 1
Level 1
Hi Jesus

Here an short update from our side

1. On our Testproject we do net see any DMA Errors when the Trap Occurs

2. We have produced 50 new PCB with the XMC4500 and they all work fine.
We have 20 PCBs with the XMC4700 which all show this trap problem.
Except the Microcontroller ther are all components the same on these PCBs.
They are even most from the same tray/package unit.

Even it is a satisfying workaround for us to use the XMC4500 we would be very interested
in getting our application to work with the XMC4700. I can only imagine that we are doing something wrong
with the XMC4700 (DMA Konfiguration, EBU Konfiguration,..) or there is an Errata we don't know.

So as I said we would be very interested in getting the XMC4700 working, so I can give you any information
you want for analyzing the problem. Maybe it is useful that you get a remote session to one of our development
computers or you got some samples from our hardware or some other information like the schematic.

Thank you for your help

Ingo
0 Likes
Not applicable
Hello Jesus,

while searching the Internet for EBU Bus Faults with the XMC4700, I found your Forum thread.
The thing is, that we are facing a very similar behaviour on the XMC4700 and the XMC4500 and we are interested if you found a workaround/solution for the described problem.

Here are some Infos about our configuration:
We connected a CPLD and an MRAM to the EBU via Chip Select.
The timing was verified with an oscilloscope, it worked perfectly without bus fault exceptions on the XMC4500 but shows exceptions on the XMC4700 sporadically.
We access the EBU via CPU.

Minor changes in our code (even in functions not called before the bus fault exceptions) results in different behaviour of the bus fault exceptions.

Can you help me too with this issue?

Thanks in advance
Karl
0 Likes
User9718
Level 1
Level 1
Hi Karl

Just a few informations for you

>> Here are some Infos about our configuration:
>> We connected a CPLD and an MRAM to the EBU via Chip Select.
>> The timing was verified with an oscilloscope, it worked perfectly without bus fault exceptions on the XMC4500 but shows exceptions on the XMC4700 sporadically.
>> We access the EBU via CPU.
We have connected a SRAM, a PSRAM, a NAND Flash and a NOR Flash with 16 Bit multiplexed Bus.
The Bus Faults can be seen on all Chip selects sporadically, but more often when acess is done via DMA than whe the Access is done via CPU.
Do you also use 16Bit demultiplexed Bus ?

>>Minor changes in our code (even in functions not called before the bus fault exceptions) results in different behaviour of the bus fault exceptions.
It is exactly the same in our projects. A minor change in the software results in a different behaviour, so this is practically not possible to debug..

Our workaround so far is to use the XMC4500. We tried some changes in the EBU Configuration but with no changes in the behaviour.
It is also very difficult to get a mini project for Jesus so that he can repoduce it because of the behaviour described above.

Regards
Ingo
0 Likes
lock attach
Attachments are accessible only for community members.
Not applicable
Hi Ingo and Jesus,

Ingo, thank you for your response.

Do you also use 16Bit demultiplexed Bus ?

No, we only use multiiplexed bus including A16 and A17 to have 18 address lanes.

It is also very difficult to get a mini project for Jesus so that he can repoduce it because of the behaviour described above.

We managed to get a minimal project that shows the described behaviour.

Jesus, I attached the project to this post, named "zebu.zip".
The project shows a bus fault after about two seconds on our hardware.
If you could use one of our test-Hardware stations let me know, i think we could easily send you one.

We tried many different configurations on different Projects.
Let me sum up our findings during testing:
- We tested two configurations,
Config 1: Setting the input clock to the EBU to synchronous mode to the AHB. The config is provided in the attached file "Zebu/cfg/ebu_cfg47.h"
Config 2: Setting the input clock to the EBU to asynchronous mode to the AHB with Setting the EBUDIV divider in SCU_CLK.EBUDIV. This config is in the file zebu/cfg/ebu_cfg47_good.h.

Config 1: The EBU_CLK equals the clock of the AHB, we tried 144 MHz and 120 MHz. We tried many changes with the remining timing parameters. We verified these on the oscilloscope and read and write accesses worked without errors but we had Bus Fault Exceptions regardless of the exact Settings.
Config 2: The EBU_CLK is derived from the PLL with the divider SCU_CLK.EBUDIV. We set this divider with respect to fCPU either to 144 MHz: 8 or 120 MHz : 6.
We found few bus faults with fCPU = 144 MHz and until now not a single bus fault with fCPU = 120 MHz.

In our understanding, the reasons for the bus faults should not depend on external devices but on the internal AHB-Interface between the EBU and the Bus Matrix, so we tried changing the EBU-Clocking configuration and adapting the external Timings accordingly.

Jesus could you please review our configuration and give a statement to the described, different behaviours between the configurations? Is Config 2 a hundred percent safe with 120 MHz?
The thing is we need a 100% working configuration with no bus faults at all so that we can get to production with the XMC Controller.

We found a similar Problem regarding bus faults on Cortex m cpus, see https://www.lpcware.com/content/forum/bus-faults-setting-lcd-display-tft
The solution there seems to be to clock the "EMC", which basically complys with the EBU, with less than the Maximum fCPU clock. This is even stated in the reference Manual of this LPC Controller.
Is there a similar hint for the XMC4700 EBU ?

Thank you for your help

Karl
0 Likes
Qu19_4750531
Level 2
Level 2
Hello Ingo/Jesus,

Did you happen to identify root cause for this issue ?
Is there any known errate which is causing this issue ?

I am seeing similar behaviour in XMC4700. I am trying to access FPGA and Flash memory over EBU.
I get interrupt from FPGA at variable frequency and i read data from FPGA and write data in Flash memory. All these operation is happening over EBU.
If i comment write to flash memory i don't see any issues which proves me that arm processor is kind of able to handle nested interrupts from FPGA. But when i perform write operation in conjunction with
serving interrupt from FPGA , randomly my code crashes into Bus fault exemption. If i track down what is causing issue i see everytime my code goes to Flash write function and then to
interrupt handler.

I have spent lot of time to investigate this issue but not able to get to root cause,

Could you please provide me some information on how did you resolve your issue ?
That might help me to debug my issue.

Looking forward to hear back from you.

Any help here is much appreciated !
0 Likes
User9718
Level 1
Level 1
Hello Query1920

The problem we had was Flash Double Bit Errors on Internal Flash when doing EBU Access. This was caused by noise from the EBU Pins.
We solved it by reducing driver strength.

Below see the Errara I got from Jesus.
I hope this helps

PORTS_CM.H002 Class A2 pins GPIO driver strength configuration

Before activating the push-pull driver, it is recommended to configure its driver strength and slew rate according to its pad class and the application needs using the Pad Driver Mode register (Pn_PDR).
Selecting the appropriate driver strength allows to optimize the outputs for the needed interface performance, can help to reduce power consumption, and limits noise, crosstalk and electromagnetic emissions (EMI).

There are three classes of GPIO output drivers:
• Class A1 pads (low speed 3.3V LVTTL outputs)
• Class A1+ pads (medium speed 3.3V LVTTL outputs)
• Class A2 pads (high speed 3.3V LVTTL outputs, e.g. for EBU or fast serial interfaces)

Class A1 pins provide the choice between medium and weak output drivers. Speed grade 6MHz.
Class A1+ pins provide the choice between strong/medium/weak output drivers. For the strong driver, the signal transition edge can be additionally selected as soft or slow. Speed grade 25MHz.
Class A2 pins provide the choice between strong/medium/weak output drivers. For the strong driver, the signal transition edge can be additionally selected as sharp/medium/soft. Speed grade 80MHz.

If the output driver strength of Class A2 pins is configured as strong/sharp care need to be taken to avoid overshoots, undershoot and ringing that may lead to high radiated emissions and crosstalk.

The high radiated emissions may lead to Bus Errors exceptions (or Hard Fault exception in case the Bus Error exception is not enabled) caused by a double bit error fail in a flash read access. Flash double bits errors are identified in the FLASH0.FSR register.

Recommendation
In general to avoid the high radiated emissions it is recommended the usage of damping resistors (10 ohms) between the high speed drivers and the transmission lines.
It is also recommended to adapt the driver strength to the needs of the application, i.e. to drive a 25MHz signal strong/medium or strong/soft would be suitable lowering the potential overshoots and undershoots.
0 Likes
Qu19_4750531
Level 2
Level 2
Hi Ibuchbau,

Thank you for the feedback, I created crash again on our system and saw Flash Single and Double bit error were set.
Looks like same issue. So i reduced driver strength to strong/Medium instead of Strong/sharp and ran it in release mode and saw system crashing again. If i reduce strength to any value lower than strong/medim then my system don't see any signal on EBU lines.

Is there anything else you did to resolve this issue apart from reducing driver strength ? Did you make any modification in hardware ?
0 Likes