XMC™ Forum Discussions

Hi folks,

I'm currently working with an XMC4500 Relax Lite Kit using DAVE v4.1.4.
To investigate the timing behavior I have written a small measurement framework that causes an interrupt after 1, 2, 3, ..., n cycles until the program subject to measurement has completed.

Main measurement framework structure:
1. initialize hardware (enable FPU)
2. initialize measurement storage (DSRAM2)
3. invalidate PMU instruction buffer
4. disable sysclock
5. setup new systick reload value
6. reset current systick value
7. enable sysclock, systick exception, setup fCPU as clock source
8. execute measurement code
9. disable syslock

SysTick_Hander structure:
1. disable systick timer
2. update measurement sample (store pc of interrupted instruction to DSRAM2)
3. update systick reload value = last value + 1
4. return to measurement framework step 3.

So, in principle I can observe the progression of the control-flow until we have reached step 9 of the measurement framework.


Currently, I'm facing an unexpected behavior when in comes to the execution of code from cached and uncached PMU FLASH memory.
Apparently, code being executed from cached PMU FLASH appears to be executed much slower.

The piece of code subject to measurement is the following (i.e., 10 iterations of "loop"):

    movs r7, #10
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop

loop:
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    sub r7, #1
    cmp r7, #0
    bne loop

    nop
    nop
    nop
    nop
    bx lr

Using the measurement framework I observe the following execution times (in cycles):

a) PREF_PCON = 0x0
FLASH0_FCPON = 0x3 (=> 3 read wait states)
Executing from PMU FLASH cached => 1809 cycles
Executing from PMU FLASH uncached => 681 cycles

b) PREF_PCON = 0x1 (=> PMU instruction buffer bypassed)
FLASH0_FCPON = 0x3 (=> 3 read wait states)
Executing from PMU FLASH cached => 681 cycles
Executing from PMU FLASH uncached => 681 cycles


How can it be that the code when being executed from PMU FLASH cached is approximately 3 times slower than when being executed from PMU FLASH uncached memory?
I have also tried to only measure the difference between the systick timer before and after the execution (i.e., no interrupts while executing the loop) with the same results.

Does anyone have a clue? What am I missing?


P.S.: I would have uploaded the full startup code, but apparently I cannot upload .S files to the forum. Show Less

Micron/Infineon Solutions
Select Micron DRAM as well as NAND and NOR flash solutions are validated on Infineon’s XMC™ microcontrollers. Minimize time spent searching for memory compatibility with XMC products.


Download the Micron/Infineon Compatibility Guide to see Micron memory solutions that support Infineon interfaces:
https://www.micron.com/~/media/documents/products/other-documents/micron_infineon_compatability_guide.pdf?la=en

More information on Micron Valued Partner Program:
https://www.micron.com/solutions/micron-valued-partner-program/chipset-partner Show Less

Multicopter – Reliable and Durable System Solutions
In Infineon's comprehensive portfolio of high quality products, you'll find the widest spectrum of multicopter components on the market.
We offer everything from XMC-controllers, to magnetic sensors, and more!



3D Printer
3D-Printing is an adaptive manufacturing technology that experts expect to change the face of industry. In this application, Industry 4.0 meets the Internet of Things (IoT). Precise and high-performance motion control is required to operate the printer, exact measurements of electrical parameters is needed for this approach. Secure transfer of data to protect the IP as well as authentication of the printed material to ensure highest quality standards are part of this application. Infineon XMC-Microcontrollers and power electronic parts like the µIPM, NovalitIC™, CoolMOS™ and HitFET™ suit this application




DAVE™ – Professional Development Platform
Eclipse-based code development platform/IDE offering a code repository, graphical system design methods and an automatic code generator to guide XMC™ microcontroller users along the entire development process – from evaluation to production (E2P). XMC™ Lib and DAVE™ generated code is tested and released for use with third-party tools.



Micriµm® Embedded Software and µC/Probe™
Micrium’s µC/Probe is a Windows application that allows you to read and write the memory of any embedded target processor during run-time, and map those values to a set of virtual controls and indicators placed on a graphical dashboard. Absolutely no programming is required – simply drag and drop the graphic components into place, and watch them go.
Show Less

Hi,

I found these two bits in the datasheet of the XMC1100: SP0 and SP1. I found them in the chapter VADC module, SHS0 registers. They are take place in the SHSCFG register. I wrote a program, which uses five input channels. I set continuous conversion.
The datasheet says about these two bits:

Sample Pending on Group x
0: No sample pending
1: Group x has finished the sample phase

I debug the program. These two bits did not change, these were always 0.

How are these bits work? Could somebody tell me?

Rjani Show Less

Hi,

after successful development of several applications using the XMC1100 for Arduino board I am in the process of transfering hardware to a customized board.
Because the software has been developed using DAVE I broke off the J-Link & UART part and connected Power, SC and SD wires to +5V/Gnd and
P014 and P15 as shown in the circuit diagramm of the board discription. Unfortunately, DAVE is not able to communicate with the device, although it still works
with the remaining eval board.
Is there anything else that needs to be considered? I could not find anything on the circuit diagram.

thanks for your help, Show Less

I'm implementing unit test code for XMC4500, and need to test the communication.

Have therefore a question: Is there any way to configure an UART into loop back mode? Show Less

Hi,

I would like to use the result interrupt and the source interrupt of VADC. But something is not correct.

Here is my code:

void VADC0_C0_0_IRQHandler(void)
{
	int result = 0;
        VADC->GLOBEFLAG |= 0x10000;                                  // Clear source event interrupt indicate bit.
	result = (VADC->GLOBRES & 0xFFFF) >> 2;
}

void VADC0_C0_1_IRQHandler(void)
{
	int result = 0;
        VADC->GLOBEFLAG |= 0x1000000;                                // Clear result event interrupt indicate bit.
	//VADC->GLOBEFLAG |= 0x10000;                                // Clear source event interrupt indicate bit.
	result = (VADC->GLOBRES & 0xFFFF) >> 2;
}



int main(void)
{
	SCU_GENERAL->PASSWD = 0xC0;		                     // Unlock protect bits. Block off.
	SCU_CLK->CGATCLR0   = 0x1;                                   // Disable gating (after disable gating, I can change VADC registers.
	while((SCU_CLK->CLKCR) & 0x40000000);	                     // Wait for VDDC to stabilize.

	SHS0->SHSCFG = 0x8000;                                       // Enable write access to ANOFF and AREF.
	SHS0->SHSCFG &= ~(SHS_SHSCFG_ANOFF_Msk);                     // Toggle on converter.
	*((int*)0x40010500) = 0x01;                                  // Workaround to enable converter: ADC_AI.003. (only stepAA).
	SHS0->SHSCFG |= 0x8800;                                      // 0x8800 = write access + internal high

	VADC->CLC = 0x00000000;                                      // Enable the module clock.

	VADC->GLOBCFG = 0x80000000;                                  // Enable Start-Up calibration.
	while ((SHS0->SHSCFG & SHS_SHSCFG_ANRDY_Msk) == 0);          // Wait until converter is ready.

	VADC->BRSSEL[0] = 0x89;	// Enable inputs: 0, 3, 7.
	VADC->BRSSEL[1] = 0x82;	// Enable inputs: 1, 7.

	VADC->GLOBICLASS[0] |= (0x01UL << VADC_GLOBICLASS_CMS_Pos);  // Set 10 bit conversion.
	VADC->GLOBICLASS[1] |= (0x01UL << VADC_GLOBICLASS_CMS_Pos);  // Set 10 bit conversion.

	VADC->GLOBRCR |= 0x80000000;	                             // Service Request Generation Enable. Service request after all result events.
        VADC->GLOBEVNP |= 0x10000;                                   // Serivce line 1.
	
        //VADC->BRSMR |= 0x8;	                                     // Source interrupt.   //   I uncomment this to the purpose of demonstration.
	//VADC->GLOBEVNP |= 0x1;                                     // Service line 1.

	//	Set interrupt channel.
	NVIC_SetPriority(VADC0_C0_0_IRQn, 3);
	NVIC_EnableIRQ(VADC0_C0_0_IRQn);

	NVIC_SetPriority(VADC0_C0_1_IRQn, 3);
	NVIC_EnableIRQ(VADC0_C0_1_IRQn);

	// Start new conversion.
	VADC->BRSMR |= 0x211;	                                     // Requests are issued, autoscan enable (automatically generate next load event), generate load event.

	while(1)
	{
	}
}

The result event works properly, but the source event not.
My problems with source vent:
- The source event is always active. Even if the ENSI bit is 0 in BRSMR register, the interrupt happens. If I set ENSI to 1, then interrupt happens as well.
- If I change the SEV0NP bitfield from 0 to 1 in GLOBEVNP register, then the interrupt stay on SR0 (the bitfield changes in DAVE).

Could somebody help me? Show Less

Why is it that if i use this.....the pin does not work....i.e. not output

XMC_GPIO_SetMode( P2_10, XMC_GPIO_MODE_OUTPUT_PUSH_PULL );


but.... if i use this ...... the pin does work.


pin_config.mode = XMC_GPIO_MODE_OUTPUT_PUSH_PULL;
XMC_GPIO_Init( P2_10, &pin_config );

???

what is the correct procedure to setup pins and does it differ from different pins types ? Show Less

Hi everybody!

I have some problems with the XMC1100 ( XMC1100-T038F0064 AA on the XMC1100 Boot Kit) and its external interrupts and timers...

The basic problem setup: I have an external signal which creates a rising edge (jump from 0 to 5V) at specific moments. I want to detect the rising edge, wait for an exact time period (between 3-60 µs) and send out a SSC data packet immediately after this time period.

I am using the ERU to generate an interrupt service routine for the rising edge, inside the SR I start one of the CCU timer slices with the wanted period value and inside the timer period SR I write the data packet into the transmit buffer of the SSC.

My problem is now, that the duration between the rising edge on the external input and the first data bit from the SSC on the TX line varies up to 0.7 µs, which is not acceptable for my application.... I could deal with constant delays but I cannot deal with this high duration differences between 2 successive rising edges...

The project worked fine with a XC164 and its "fast external interrupts", so I don't think that there is any problem with the external hardware (external rising edges are very stable)

I have also tried to use the CCU for creating the external interrupt SR instead of the ERU and have also tried to use the System Ticker as Timer instead of the CU timer... but the jitter remains (nearly) the same...

After some error searching with debug pins I can say: Approx. half of the jitter occurs between the external rising edge and entering the ERU interrupt SR and the other half occurs between starting the timer and writing to the SSC transmit buffer.

You can find my basic code in the attachment...

Does anybody has an idea what I am doing wrong or has an idea who to do it better??? Or do I have to accept this jitter (although I am very surprised that such a basic algorithm can vary up to 0.7 µs)

best Robert

P.s. I really want to do this with a XMC1100 Boot kit and without Dave Apps, so please don't tell me which MC is better 🙂 Show Less

Dear Infineon,

by reading the latest errata sheet for the new XMC4700 series, I discovered an entry regarding the
USIC parity mode.
I know this bug from our old XMC4500 micros.
Infineon fixed this bug in new steppings of the XMC4400 series, but not in the 4500er.

When we started our new project we asked Infineon about this bug in future micros and we got the feedback
that it will not be in the upcoming 4700er.
This project need to have two independant Modbus RTU interfaces, so we need to have parity mode.

Does the design of the XMC4700 really base on the old XMC4500 steppings and not on new ones?

Or is it just a copy-paste-error from an errata sheet of the XMC4500 series?

I really need reliable feedback on this issue, because this bug would stop our whole development.

Michael Show Less