XMC™ Forum Discussions

Hi,
How to use the XMClib to program the XMC44 Posif peripheral. I want to use the posif in the encoder mode, with phase A, phase B and index inputs and capture the position count and velocity.

Ari. Show Less

Hello again,
Our prototype is at customers site and is under test and measurement. But we have been informed about the following issue. The customer has a DMX console which is quite old, with these sliding potentiometers and 48 channels or something. He claims that the DMX is not working. He sent some pictures from his oscilloscope and I noticed that after the last byte the line remain high, the break and MAB fields are ok but I don't know why the DMX application is not working, the callback is not called?! Is it possible this to be because I need all 512 bytes?! 512th slot has an application specific purpose... Please suggest how to solve this. Fortunately the customer uses the analogue inputs to test and measure the lightning device but the main command will be through DMX.

Thanks Show Less

Emtas released the first version of the CANopen driver package using Infineon’s DAVE™ (version 4) for the CANopen protocol stack implementing CiA 301 version 4.2.
The CANopen driver supports all members of the XMC4000 Microcontroller portfolio ranging from XMC4108 to XMC4500 with a MultiCAN module that offers up to three CAN nodes with up to 64 message objects.



The new release of emtas CANopen driver and protocol stack ensures flexible and configurable use of the CANopen protocol in Full CAN mode, Basic CAN mode, or Basic CAN mode with hardware RX FIFO. It is implemented MISRA-C conform according to the latest CiA communication profile 301 V4.2 for classic CAN and NMT master functionality following CiA 302-2 including CiA 305 LSS services.

It is well suited to develop devices following the CiA device profiles and for Energybus products. The CANopen development process is supported by tools to generate the object dictionary and test tools for automated device tests.


View the full article here:
http://bit.ly/emtas_CANopen

For more information:
http://www.emtas.de/en
http://www.emtas.de/partner/infineon
www.infineon.com/xmc
www.infineon.com/dave Show Less

Hi,

I'm currently trying to use the initial version of the XMC_Peripheral_Library_v1.0.0 specifically the usb device driver. In order to initalize the USB device it is necessary to fill an USB Device Initialization Structure XMC_USBD_t. The first member of this structure is USB0_GLOBAL_TypeDef *const usbd and is registered as a read-only member. So if I'm trying to fill this member with the USB Module Base Address it triggers a compiler error because I'm trying to write to a read-only member. Could that be a bug or do I need to call another function first which fills this structure with default values? Furthermore if I delete the const keyword for this member and I store the USB Base Module Address in it and I call the XMC_USBD_Init() function the 32-bit Base Address is stored in a variable called XMC_USBD_BASE_ADDRESS which is a uint8_t *. Shouldn't the datatype for the variable XMC_USBD_BASE_ADDRESS be a uint32_t *?

Code snippets:

USER_APP:

XMC_USBD_t usb_config;

usb_config.usbd = (USB0_GLOBAL_TypeDef const *)USB0;
usb_config.cb_xmc_device_event = NULL;
usb_config.cb_endpoint_event = NULL;
usb_config.usbd_max_num_eps = XMC_USBD_MAX_NUM_EPS_1;
usb_config.usbd_transfer_mode = XMC_USBD_USE_DMA;

XMC_USBD_Init(&usb_config);

XMC_USBD (c-file):

uint8_t *XMC_USBD_BASE_ADDRESS;

XMC_USBD_BASE_ADDRESS = (uint8_t *)(obj->usbd);

xmc_device.global_register = (dwc_otg_core_global_regs_t*)(obj->usbd);

XMC_USBD (h-file):

typedef struct XMC_USBD_OBJ
{
USB0_GLOBAL_TypeDef *const usbd; /**< USB Module Pointer. The USB0 module base address. */
XMC_USBD_SignalDeviceEvent_t cb_xmc_device_event; /**< USB device event callback. Use ::XMC_USBD_SignalDeviceEvent_t type of function pointer. */
XMC_USBD_SignalEndpointEvent_t cb_endpoint_event; /**< USB endpoint event callback. Use ::XMC_USBD_SignalEndpointEvent_t type of function pointer.*/
XMC_USBD_MAX_NUM_EPS_t usbd_max_num_eps; /**< Maximum number of end points used. The maximum range can be 7.*/
XMC_USBD_TRANSFER_MODE_t usbd_transfer_mode; /**< USB data transfer mode.Use ::XMC_USBD_TRANSFER_MODE_t type to specify the transfer mode. */
} XMC_USBD_t;

Thanks,

Roman Show Less

Hi All,

I have a problem to output the correct PWM signal when set duty cycle as 100%.
In my program, I set the PWM duty cyle as 100%, 100%, 100%, 80%, 50%, 25%, 100%......, the period value is 250us, all the compare values are updated only at the One match event.

From the scope, I can see the PWM signal with duty cycle 80% (after the signal of duty cycle 100%) is not symmetrical,
I assume the correct PWM signal should be the one shown in second picture.

Could someone please give me some suggestions? Thanks a lot.

Show Less

Currently working to overcome a hardware issue on a PCB. Effectively looking to use the SPI001 App to handle SPI comms to an external DAC but have a GP Output pin acting as an additional Slave Select line which will actually connect to the external DAC. For information I'm using the XMC4500 (144 Pin) Hex Development kit and using the debugger/a TEK MSO2042 scope to debug.

Successfully managed to configure the SPI001 App however I am having issues with a GP DigOut to act as a Slave Select. I have attached a very simple example project which exhibits the bug which hopefully details and exhibits the issue I'm seeing.

The code attached is simply writing some data to the SPI bus, whilst this data is being written I have set P0.0 low. Upon completion of the data being transmitted it is set back high. As shown in the attached scope trace P0.0 (Ch4 - Green) is clearly only staying low for a short duration prior to any data being written to the SPI bus. Below is the function I am periodically calling to write data to the SPI bus.

void SPIWrite()
	{
	uint16_t Data;

		P0_0_reset();

		for(Data = 0; Data < 10; Data++)
		{
			SPI001_WriteData(&SPI001_Handle0,&Data,SPI001_STANDARD_HPC_OUTPUTMODE );
		}
		P0_0_set();
	}

I have attempted using different GPIO pins on the device which repeat the same results. I have commented out the SPI001_WriteData call, this resolves my issue so suspect that somewhere within the DaveApp/generated code the output is being reset.

One interesting thing I have found is that stepping through the code line by line in the debugger does not show the fault. But free running the code in the debugger/running code without the debugger exhibits the fault.

Has anyone experienced similar issues? Any guidance/tips/ideas would be really appreciated! Have included some further detail below. Apologies if lacking detail.

Cheers

Dave

*********************************************************************************************
This has been achieved using the below project:



DaveVersion - 3.1.10 (Installer Build 2014-05-23)
SPI001 App Version - 1.0.24

The below scope trace details the reality of what is happening with thecode:



Ch1 - Yellow SCK P0.11
CH2 Blue MOSI P0.5
Ch3 Pink ChipSelectA P0.6
Ch4 Green GP DigOut P0.0 Show Less

Hi,
Here anyone implemented printf() over VCOM in XMC 4500.,for debugging i need to send data over usb to hyper terminal,i have made certain changes in traditional printf which is based on UART.even though it is printing only first two characters.

Regards,
Irfan. Show Less

Hello,

I'm writing this thread to call attention to something which I feel is very misleading in the USIC application note.

On page 17, the note specifically states:



In my opinion this is really ambiguous. The correct behavior is to simultaneously write a value to the DPTR field and 0 to the SIZE field (atomically), but the writing implies that one should first write a 0 to the SIZE field and only AFTER that should one write to the DPTR field. This ambiguity took me forever to figure out and I really wish it was specified more clearly. In order to figure out the correct behavior I had to look at the DAVE generated code.

--J Show Less

When using UART with FIFO buffer, there is no indication provided when the last data in the FIFO buffer had transmitted out.
Due to this, if application that require this indication may find it difficult to implement.

Here, we would like to introduce a workaround to get this indication.
When USIC In UART mode, there is a flag to indicates frame finished event (PSR.TFF).
This flag is set when the each data byte is finished transmit out. (Word length = Frame length = 8-bit)
So, by polling this flag (or set an interrupt) to count the number of data has been transfer out, we know exactly how many data has been transmitted out.
When the number of bytes push to the FIFO match the number of bytes count by the frame finished flag, this indicated the last data has been transmitted out.

Note: Each time after the flag is set, the flag has to be cleared immediately in order to count the next frame finish event. Show Less

I have a large firmware application running on a Relax Board. One function creates and writes FAT files to the SDCard with the DAVE3 SLTHA001. Another function sets variables by writing to three SPI001 digital potentiometer devices. I've discovered that the writing to the SDCard fails whenever I've made a call to the SPI001_WriteData ( ... ) function. This function works otherwise as verified by the SYNC, SCLK and MOSI signal wave forms on an oscilloscope. Has anyone else seen a conflict between the SPI and SDMMC functionality of DAVE3? Show Less