XMC™ Forum Discussions
XMC™
Hello In an encloded description I found that XMC 4700 has 6ch CAN FD (http://www.can-cia.org/can-knowledge/can/can-fd/)in its MultiCAN+ unit. But I d...
Show More
Hello
In an encloded description I found that XMC 4700 has 6ch CAN FD (http://www.can-cia.org/can-knowledge/can/can-fd/)
in its MultiCAN+ unit. But I did not find this information elsewhere. Is it true? Show Less
In an encloded description I found that XMC 4700 has 6ch CAN FD (http://www.can-cia.org/can-knowledge/can/can-fd/)
in its MultiCAN+ unit. But I did not find this information elsewhere. Is it true? Show Less
XMC™
- The position of a conversion result value within the selected result register depends on 3 configurations.
- The selected result width (12/10/8 bits, selected by the conversion mode)
- The selected result position (Left/Right-aligned) Show Less
- The position of a conversion result value within the selected result register depends on 3 configurations. - The selected result width (12/10/8 bits...
Show More
- The position of a conversion result value within the selected result register depends on 3 configurations.
- The selected result width (12/10/8 bits, selected by the conversion mode)
- The selected result position (Left/Right-aligned) Show Less
XMC™
Hi!I'm trying to configure the SPI interface using the DAVE app SPI_MASTER. I set up everything and looked at the waveforms in my oscilloscope.I made ...
Show More
Hi!
I'm trying to configure the SPI interface using the DAVE app SPI_MASTER. I set up everything and looked at the waveforms in my oscilloscope.
I made several screenshots with different clocks.
This is for 10MHz:
This is for 20MHz:
And this is for 25MHz:
So what is happening at 25MHz? Why is the clock looking so ugly? At 20MHz it seems fine. Does anyone have an idea?
Thanks!
Regards,
Milad Show Less
I'm trying to configure the SPI interface using the DAVE app SPI_MASTER. I set up everything and looked at the waveforms in my oscilloscope.
I made several screenshots with different clocks.
This is for 10MHz:
This is for 20MHz:
And this is for 25MHz:
So what is happening at 25MHz? Why is the clock looking so ugly? At 20MHz it seems fine. Does anyone have an idea?
Thanks!
Regards,
Milad Show Less
XMC™
XMC™ trainings are available on the XMC4000 and XMC1000 product websites.Introduction to Microcontroller World - newApplication - Lighting - XMC ...
Show More
XMC™ trainings are available on the XMC4000 and XMC1000 product websites.
The training materials can be downloaded from the respective XMC™ product pages, under Documents >> Training:
XMC4000
XMC1000
Show Less
- Introduction to Microcontroller World - new
- Application - Lighting - XMC in LED Lighting Applications - updated
The training materials can be downloaded from the respective XMC™ product pages, under Documents >> Training:
XMC4000
XMC1000
Show Less
XMC™
Hi all,I have a question regarding the mapping of DMA registers with SW structures. One can find the following structure data type in `xmc_dma.h`.Howe...
Show More
Hi all,
I have a question regarding the mapping of DMA registers with SW structures. One can find the following structure data type in `xmc_dma.h`.
However, the reference manual shows the layout a bit differently, as seen below.
It is relatively straightforward that the members of the structure are arrays that represent collections of registers (i.e. RAWTFR, RAWBLOCK, RAWSRCTRAN... are collected under RAWCHEV[10]). Also, I have no question regarding the size of arrays - for instance, RAW* array is 32 bits long and there is 8 bits of space between 02E0 and 02E8, where STATUS* starts.
What I don't understand is why STATUSCHEV, which is seemingly supposed to contain STATUS* register values (that are obtained by passing RAW* values and MASK* values through a bit-wise AND gate, if I were to speculate), contains the values that belong in STATUSINT? To explain, a workspace search (CTRL+ALT+G) for STATUSCHEV invocation returns the following results,
There are 4 other invocations that access array members [2], [4] and so forth, until [8]. These accesses fetch the combined status, which - what it seems like - is supposed to be done by accessing STATUSINT. On the other hand, STATUSINT is not invoked at all (again, as per workspace search).
Now, the question is - which register is which. And as a follow-up - is there any file that is generated by the compiler that would show the mapping of such structures to peripheral registers? (I am thinking along the lines of .map files that show the mapping of variables in memory, etc.)
Edit: While we are on the topic of DMAs, I was wondering if the programmable registers are the ones that GPDMA actually uses, or are there shadow registers that programmable registers are copied into?
Thank you in advance and best regards,
Andrey Show Less
I have a question regarding the mapping of DMA registers with SW structures. One can find the following structure data type in `xmc_dma.h`.
However, the reference manual shows the layout a bit differently, as seen below.
It is relatively straightforward that the members of the structure are arrays that represent collections of registers (i.e. RAWTFR, RAWBLOCK, RAWSRCTRAN... are collected under RAWCHEV[10]). Also, I have no question regarding the size of arrays - for instance, RAW* array is 32 bits long and there is 8 bits of space between 02E0 and 02E8, where STATUS* starts.
What I don't understand is why STATUSCHEV, which is seemingly supposed to contain STATUS* register values (that are obtained by passing RAW* values and MASK* values through a bit-wise AND gate, if I were to speculate), contains the values that belong in STATUSINT? To explain, a workspace search (CTRL+ALT+G) for STATUSCHEV invocation returns the following results,
There are 4 other invocations that access array members [2], [4] and so forth, until [8]. These accesses fetch the combined status, which - what it seems like - is supposed to be done by accessing STATUSINT. On the other hand, STATUSINT is not invoked at all (again, as per workspace search).
Now, the question is - which register is which. And as a follow-up - is there any file that is generated by the compiler that would show the mapping of such structures to peripheral registers? (I am thinking along the lines of .map files that show the mapping of variables in memory, etc.)
Edit: While we are on the topic of DMAs, I was wondering if the programmable registers are the ones that GPDMA actually uses, or are there shadow registers that programmable registers are copied into?
Thank you in advance and best regards,
Andrey Show Less
XMC™
I am trying to use the DMA to transfer data from memory to the USIC in I2S mode.My data is a 200 word 16bit array. The USIC is set to transfer 16 bits...
Show More
I am trying to use the DMA to transfer data from memory to the USIC in I2S mode.
My data is a 200 word 16bit array. The USIC is set to transfer 16 bits.
I have programed the DMA with Block size 200 and source and destination as 16 bit.
When I start the transfer only every second word is output via the I2S bus. A total of 100 values are transferred.
Something must be wrong with my settings, but I do not understand what. Can someone with DMA experience help me? Show Less
My data is a 200 word 16bit array. The USIC is set to transfer 16 bits.
I have programed the DMA with Block size 200 and source and destination as 16 bit.
When I start the transfer only every second word is output via the I2S bus. A total of 100 values are transferred.
Something must be wrong with my settings, but I do not understand what. Can someone with DMA experience help me? Show Less
XMC™
I am trying to use the DMA to transfer multi-blocks of data from memory to the TBUF of a USIC. The DMA is set to Hardware handshake for the destinatio...
Show More
I am trying to use the DMA to transfer multi-blocks of data from memory to the TBUF of a USIC. The DMA is set to Hardware handshake for the destination.
The behavior at the moment is totally unpredictable. Sometimes it works correctly and sometimes only 0xFFFF is transferred.
There are 2 things that seem strange to me:
1. The DMA transfer starts immediately when it is enabled. As the transmit buffer interrupt from the USIC is a pulse I would expect to have to trigger the interrupt by software to start the DMA transfer. Is the behavior normal or have I set the USIC interrupt incorrectly?
2. The Overrun bit in the DLR is getting set. According to the documentation this only happens when the next Service Request comes before the DMA acknowledges the previous request. I cannot believe the DMA is taking longer to acknowledge the interrupt than the USIC needs to transmit 16bits of data. What could be the problem here? Does the overrun status have an effect on the next service request?
I cannot find any reason why the DMA is not working reliably. The above points are only a guess of what may be going wrong.
Does anyone have an example of DMA transfers from memory to peripheral using link lists? Show Less
The behavior at the moment is totally unpredictable. Sometimes it works correctly and sometimes only 0xFFFF is transferred.
There are 2 things that seem strange to me:
1. The DMA transfer starts immediately when it is enabled. As the transmit buffer interrupt from the USIC is a pulse I would expect to have to trigger the interrupt by software to start the DMA transfer. Is the behavior normal or have I set the USIC interrupt incorrectly?
2. The Overrun bit in the DLR is getting set. According to the documentation this only happens when the next Service Request comes before the DMA acknowledges the previous request. I cannot believe the DMA is taking longer to acknowledge the interrupt than the USIC needs to transmit 16bits of data. What could be the problem here? Does the overrun status have an effect on the next service request?
I cannot find any reason why the DMA is not working reliably. The above points are only a guess of what may be going wrong.
Does anyone have an example of DMA transfers from memory to peripheral using link lists? Show Less
XMC™
I am using ADCSYNC to sample 4 channels simultaneously. The adc fills up 4 arrays which is subsequently transmitted to a host pc over USB upon reachin...
Show More
I am using ADCSYNC to sample 4 channels simultaneously. The adc fills up 4 arrays which is subsequently transmitted to a host pc over USB upon reaching a predefined number of samples. Before USB transmission is initiated the sampling interrupt is stopped.
It seems, however, that somehow the USB is writing to a certain memory address which is also contained in one of my data arrays, and I loose that particular data.
The problem occurs at the same address every time (word at 0x20000CD0). Using the debugger I could assert that the data is sampled correctly, but when the code proceeds to USB tasks the particular memory is overwritten before being transmitted to the host.
I cannot identify the precise command that is responsible for the write operation, but I am convinced that is the usb - watchpoint does not pick it up???
The above happens with the USBD_VCOM app on the XMC4400.
When I try to use the old app (USBVC001) I get a busfault error. In this case I can identify (using watchpoints) that the USB app is again using memory that overlaps with my data array. When transmission begins the mcu hangs and it indicates a busfault.
How should I try to debug this behavior and how can I find the process that is violating my data? Is there a way to specify the address where I initialize my data arrays to maybe avoid the overlap?
Regards,
Frik Show Less
It seems, however, that somehow the USB is writing to a certain memory address which is also contained in one of my data arrays, and I loose that particular data.
The problem occurs at the same address every time (word at 0x20000CD0). Using the debugger I could assert that the data is sampled correctly, but when the code proceeds to USB tasks the particular memory is overwritten before being transmitted to the host.
I cannot identify the precise command that is responsible for the write operation, but I am convinced that is the usb - watchpoint does not pick it up???
The above happens with the USBD_VCOM app on the XMC4400.
When I try to use the old app (USBVC001) I get a busfault error. In this case I can identify (using watchpoints) that the USB app is again using memory that overlaps with my data array. When transmission begins the mcu hangs and it indicates a busfault.
How should I try to debug this behavior and how can I find the process that is violating my data? Is there a way to specify the address where I initialize my data arrays to maybe avoid the overlap?
Regards,
Frik Show Less
XMC™
Good After noon every one,I am working with XMC1100 microcontrller, I have configured UART to USIC0_CH1. I am Sending one command to another controlle...
Show More
Good After noon every one,
I am working with XMC1100 microcontrller, I have configured UART to USIC0_CH1. I am Sending one command to another controller.
when i do POWER on reset, After that when i send the command 1st time the other controller is get hanged.after resetting that controller then there is no communication problem.
this is happening Afert POWER ON RESET.
can anybody please tell me, what might be the problem...
Best Regards,
Srikanth. Show Less
I am working with XMC1100 microcontrller, I have configured UART to USIC0_CH1. I am Sending one command to another controller.
when i do POWER on reset, After that when i send the command 1st time the other controller is get hanged.after resetting that controller then there is no communication problem.
this is happening Afert POWER ON RESET.
can anybody please tell me, what might be the problem...
Best Regards,
Srikanth. Show Less
XMC™
Hello,In the reference manual (RM), there are apparently two ways to configure the Digital input on port 14 and 15, because they are both analog and d...
Show More
Hello,
In the reference manual (RM),
there are apparently two ways to configure the Digital input on port 14 and 15, because they are both analog and digital port, cf p2782.
Do I have to use the register PDISC or IOCR12 ? Or it doesn't matter for digital input ?
I tried different configuration for the register IOCR12.
Any help please ?
In the reference manual (RM),
there are apparently two ways to configure the Digital input on port 14 and 15, because they are both analog and digital port, cf p2782.
Do I have to use the register PDISC or IOCR12 ? Or it doesn't matter for digital input ?
I tried different configuration for the register IOCR12.
Any help please ?
Show Less
#include//Declarations from DAVE Code Generation (includes SFR declaration)
/**
* @brief main() - Application entry point
*
* Details of function
* This routine is the application entry point. It is invoked by the device startup code. It is responsible for
* invoking the APP initialization dispatcher routine - DAVE_Init() and hosting the place-holder for user application
* code.
*/
volatile uint32_t var1;
int main(void)
{
DAVE_STATUS_t status;
status = DAVE_Init(); /* Initialization of DAVE APPs */
var1 = 0;
// -------------- LED1 Configuration -------------------------------------------------
PORT5->IOCR8 |= 0b00000000000000001000000000000000;
PORT5->OMR |= 0b00000010000000000000000000000000; // LED off
// --------------- Button1 Configuration ----------------------------------------------
PORT15->PDISC &= 0b11111111111111111101111111111111; // 0 ; digital pad enabled
//PORT15->IOCR12 |= 0b00000000000000000011100000000000; // no internal pull device active, continuously sample the inverted input value
//PORT15->IOCR12 |= 0b00000000000000000001100000000000; // no internal pull device active, continuously sample the input value
// PORT15->IOCR12 |= 0b00000000000000000000000000000000; // no internal pull device active, direct input value
if(status == DAVE_STATUS_FAILURE)
{
/* Placeholder for error handler code. The while loop below can be replaced with an user error handler. */
XMC_DEBUG("DAVE APPs initialization failed\n");
while(1U)
{
//ERROR
}
}
/* Placeholder for user application code. The while loop below can be replaced with user application code. */
while(1U)
{
/* test bit 13 of PORT15 : */
if ( ( PORT15->IN & (1u << 13) ) != 0 )
{
PORT5->OMR |= 0b00000000000000000000001000000000;
var1++;
}
}
}