XMC™ Forum Discussions
text.format{('custom.tabs.no.results')}
Sort by:
XMC™
Hi!
Can the USIC.SSC function in DDR (double data rate) mode?
USIC.SSC functions in master mode.
Thank you in advance for your help.
Can the USIC.SSC function in DDR (double data rate) mode?
USIC.SSC functions in master mode.
Thank you in advance for your help.
XMC™
Hi,I am trying to run µc/Probe with an XMC 4200F64x256.But it crashes all the time, when I try to run. (I have never seen something like that)Those ar...
Show More
Hi,
I am trying to run µc/Probe with an XMC 4200F64x256.
But it crashes all the time, when I try to run. (I have never seen something like that)
Those are the steps i did before pressing play:
1. selected the correct *.elf file.
2. switched to XMC4000 family.
3. Added a linear gauge (vertial 1)
4. Dropped one of the variables onto it.
5. Clicked the variable in the symbols manager of the vertical 1.
6. Software is running on the MCU.
7. Debugger is connected.
8. in µC / Probe it is configures as SWD and 1000khz (those are the settings in my DAVE configuration)
6. Pressed play.
7. CRASH
This is the error:
Date: 6/13/2017 1:29:43 PM
µC/Probe Version: 4.2.1.544
µC/Probe Edition: Pro
CommunicationType: SeggerJLinkSettings
Culture: en-US
SymbolFile: NULL
DotNetVersion: 4.0.30319.42000
OsMajorVersion: 6
OsMinorVersion: 2
OsPlataform: Win32NT
Error Message: Value cannot be null.
Parameter name: source
InnerException: NULL
StackTrace: at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source)
at Micrium.Ucprobe.Modules.Docking.Screens.ViewModel.OS2.KA.Tasks.OS2_KA_Tasks_ViewModel.Start(CommunicationSettings settings, Boolean isFirstTime)
at Micrium.Ucprobe.Modules.Docking.Screens.ViewModel.OS2.KA.OS2_KA_ViewModel.Start(CommunicationSettings settings, Boolean newOS_NetCode)
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.SetAwarenessScreensForStart()
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.SetDispatcherForStart()
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.Start()
at Micrium.Ucprobe.ApplicationSystem.Application.AppSystem.StartCollectingData()
at Micrium.Ucprobe.ApplicationSystem.Tools.CustomVersion.Infineon.Infineon_Version_Properties.CheckValue(Int32 valueToCheck)
at Micrium.Ucprobe.ApplicationSystem.Tools.CustomVersion.Infineon.Infineon_Version_Properties.Update(ControlUpdate update)
at Micrium.Ucprobe.ApplicationSystem.SymbolsManagment.SymbolsDispatcher.<>c__DisplayClass3.b__2()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
Show Less
I am trying to run µc/Probe with an XMC 4200F64x256.
But it crashes all the time, when I try to run. (I have never seen something like that)
Those are the steps i did before pressing play:
1. selected the correct *.elf file.
2. switched to XMC4000 family.
3. Added a linear gauge (vertial 1)
4. Dropped one of the variables onto it.
5. Clicked the variable in the symbols manager of the vertical 1.
6. Software is running on the MCU.
7. Debugger is connected.
8. in µC / Probe it is configures as SWD and 1000khz (those are the settings in my DAVE configuration)
6. Pressed play.
7. CRASH
This is the error:
Date: 6/13/2017 1:29:43 PM
µC/Probe Version: 4.2.1.544
µC/Probe Edition: Pro
CommunicationType: SeggerJLinkSettings
Culture: en-US
SymbolFile: NULL
DotNetVersion: 4.0.30319.42000
OsMajorVersion: 6
OsMinorVersion: 2
OsPlataform: Win32NT
Error Message: Value cannot be null.
Parameter name: source
InnerException: NULL
StackTrace: at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source)
at Micrium.Ucprobe.Modules.Docking.Screens.ViewModel.OS2.KA.Tasks.OS2_KA_Tasks_ViewModel.Start(CommunicationSettings settings, Boolean isFirstTime)
at Micrium.Ucprobe.Modules.Docking.Screens.ViewModel.OS2.KA.OS2_KA_ViewModel.Start(CommunicationSettings settings, Boolean newOS_NetCode)
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.SetAwarenessScreensForStart()
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.SetDispatcherForStart()
at Micrium.Ucprobe.Controls.Common.ControlDispatcher.Start()
at Micrium.Ucprobe.ApplicationSystem.Application.AppSystem.StartCollectingData()
at Micrium.Ucprobe.ApplicationSystem.Tools.CustomVersion.Infineon.Infineon_Version_Properties.CheckValue(Int32 valueToCheck)
at Micrium.Ucprobe.ApplicationSystem.Tools.CustomVersion.Infineon.Infineon_Version_Properties.Update(ControlUpdate update)
at Micrium.Ucprobe.ApplicationSystem.SymbolsManagment.SymbolsDispatcher.<>c__DisplayClass3.
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
XMC™
Hi,I am right that the maximum EEPROM size is 8kB? Why is it not 16kB because each of the 4 sectors has 16kB?I do not understand why there is a 64kB ...
Show More
Hi,
I am right that the maximum EEPROM size is 8kB? Why is it not 16kB because each of the 4 sectors has 16kB?
I do not understand why there is a 64kB FLASH_0 in the linker file. Then the EEPROM 64kB and then
FLASH_1. But the FLASH_0 is only needed for reset. Is it not possible to place the EEPROM at the end
of the flash? Because with this setting i have lost some kbytes.
FLASH_0_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x010000
FLASH_0_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x010000
FLASH_1_cached(RX) : ORIGIN = 0x08020000, LENGTH = 0xE0000
FLASH_1_uncached(RX) : ORIGIN = 0x0C020000, LENGTH = 0xE0000
PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0x10000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000
DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000
many thanks Show Less
I am right that the maximum EEPROM size is 8kB? Why is it not 16kB because each of the 4 sectors has 16kB?
I do not understand why there is a 64kB FLASH_0 in the linker file. Then the EEPROM 64kB and then
FLASH_1. But the FLASH_0 is only needed for reset. Is it not possible to place the EEPROM at the end
of the flash? Because with this setting i have lost some kbytes.
FLASH_0_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x010000
FLASH_0_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x010000
FLASH_1_cached(RX) : ORIGIN = 0x08020000, LENGTH = 0xE0000
FLASH_1_uncached(RX) : ORIGIN = 0x0C020000, LENGTH = 0xE0000
PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0x10000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000
DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000
many thanks Show Less
XMC™
Hello everyone,I'm trying to setup a symmetric PWM with the CCU4 Module with DAVE4.3 for a XMC4700.I've been looking how to enable the transfer of the...
Show More
Hello everyone,
I'm trying to setup a symmetric PWM with the CCU4 Module with DAVE4.3 for a XMC4700.
I've been looking how to enable the transfer of the shadow registers only at the 'one-match' event instead of twice per period.
I noticed that the XMCLib function "XMC_CCU4_SLICE_SetShadowTransferMode()" is only available for the XMC1400 series.
Is it possible to configure the CCU4 to work in symmetric mode so that the compare match value is updated only at the beginning of the PWM period (one-match)?
Regards,
Sebastian Show Less
I'm trying to setup a symmetric PWM with the CCU4 Module with DAVE4.3 for a XMC4700.
I've been looking how to enable the transfer of the shadow registers only at the 'one-match' event instead of twice per period.
I noticed that the XMCLib function "XMC_CCU4_SLICE_SetShadowTransferMode()" is only available for the XMC1400 series.
Is it possible to configure the CCU4 to work in symmetric mode so that the compare match value is updated only at the beginning of the PWM period (one-match)?
Regards,
Sebastian Show Less
XMC™
Hi,for our next project I want to have an external RAM connected to our XMC 4700.But I ran into the problem that P0.7 is being used for JTAG TDI AND A...
Show More
Hi,
for our next project I want to have an external RAM connected to our XMC 4700.
But I ran into the problem that P0.7 is being used for JTAG TDI AND AD[6]...
Even in the BGA package.
I have an ULINK PRO with ETM support.
Because it's AD[6], even using just a 8 bit interface is no workaround. If it would be AD[31] it would
not create a problem with a 8 or 16 bit interface.
How can one use the JTAG if the external bus interface is being used, too?
I assume that even when ETM is being used, JTAG is needed, too. Correct?
Michael Show Less
for our next project I want to have an external RAM connected to our XMC 4700.
But I ran into the problem that P0.7 is being used for JTAG TDI AND AD[6]...
Even in the BGA package.
I have an ULINK PRO with ETM support.
Because it's AD[6], even using just a 8 bit interface is no workaround. If it would be AD[31] it would
not create a problem with a 8 or 16 bit interface.
How can one use the JTAG if the external bus interface is being used, too?
I assume that even when ETM is being used, JTAG is needed, too. Correct?
Michael Show Less
XMC™
I'm looking at XMC1200 GPIO block diagram trying to wrap my head around everything.I'm trying to figure out what the "FF" block is. I don't see any re...
Show More
I'm looking at XMC1200 GPIO block diagram trying to wrap my head around everything.
I'm trying to figure out what the "FF" block is. I don't see any reference to "FF" in the following documentation and all the other blocks align with control registers.
Any idea what the "FF" block is?
Show Less
I'm trying to figure out what the "FF" block is. I don't see any reference to "FF" in the following documentation and all the other blocks align with control registers.
Any idea what the "FF" block is?
Show Less
XMC™
Dear All,I am using following VADC channels with groups.=====================================GROUP 0 GROUP 1=========================...
Show More
Dear All,
I am using following VADC channels with groups.
The VADC should start scan on every rising edge of CCU8(PWM) trigger point.
How VADC should be configured to achieve this?
1) I should use Background request source or scan request source or queue request source.
2) As the channels are from different groups, which technique is to be implemented to achieve this.
3) When should we use background / scan request / queue request?
Please guide me.
Regards,
Tinchu Show Less
I am using following VADC channels with groups.
=====================================
GROUP 0 GROUP 1
=====================================
CH0 CH1
CH7 CH5
CH7
=====================================
The VADC should start scan on every rising edge of CCU8(PWM) trigger point.
How VADC should be configured to achieve this?
1) I should use Background request source or scan request source or queue request source.
2) As the channels are from different groups, which technique is to be implemented to achieve this.
3) When should we use background / scan request / queue request?
Please guide me.
Regards,
Tinchu Show Less
XMC™
Hi!I am using USIC in SSC-mode over DMA.word size: 8bit;mode: singe-SPI in master-mode;I program two DMA channels (receive and transmit) for service o...
Show More
Hi!
I am using USIC in SSC-mode over DMA.
word size: 8bit;
mode: singe-SPI in master-mode;
I program two DMA channels (receive and transmit) for service of SPI. DMA works with the burst size: BURST_SPI == 4 (GPDMA_CH.CTLL.MSIZE == BURST_SPI).
USIC.SSC FIFO size == 16.
RBCTR.LIMIT = BURST_SPI-1; RBCTR.SRBTM == 0; RBCTR.SRBTEN == 0; RBCTR.RNM == 0; RBCTR.LOF == 1; RBCTR.SRBIEN == 1; RBCTR.RBERIEN == 1.
TBCTR.LIMIT = BURST_SPI; TBCTR.STBTM == 0; TBCTR.STBTEN == 0; TBCTR.LOF == 0; TBCTR.STBIEN == 1; TBCTR.TBERIEN == 1.
I set the priority of the DMA.TX-channel to be lower than the priority DMA.RX-channel (GPDMA_CH.CFGL.CH_PRIOR).
I enabled interrupt from RX-DMA-channel (GPDMA.MASK.TFR) after completing transfer entire block.
I pass a 16-bytes block to the SPI.
If SCLK SPI was <= SYSTEM_CLK/4 - all ok - I received single interrupt, no troubles, all data transmitted/received correctly.
If SCLK SPI was == SYSTEM_CLK/2 - in this case, I get the error state "reading an empty receive buffer" (USIC.TRBSR.RBERI == 1). And I recives invalid data (duplicated bytes).
Trying to correct this error, I reduce the value: TBCTR.LIMIT = 1. This underflow error now occurs less often, but it still happens (not with a block size of 16 bytes, but starting with about ~ 1024 bytes and bigger).
I think the scenario for occuring the error is (for TBCTR.LIMIT = 1):
TX.FIFO RX.FIFO
0 0 ;DMA.TX writes BURST_SPI bytes to TX.FIFO (1-st burst)
4 0
3 0 ;TX.FIFO -> TX.SHIFT register (1-st byte)
3 1 ;was transmitted/received last bit of 1-st byte
2 1 ;TX.FIFO -> TX.SHIFT register (2-nd byte)
2 2 ;was transmitted/received last bit of 2-nd byte
1 2 ;TX.FIFO -> TX.SHIFT register (3-rd byte)
1 3 ;was transmitted/received last bit of 3-rd byte
0 3 ;TX.FIFO -> TX.SHIFT register (4-th byte); DMA.TX event -> DMA.TX writes new BURST_SPI bytes to TX.FIFO (2-nd burst)
4 3
4 4 ;was transmitted/received last bit of 4-th byte;
At this point, the event DMA.RX is generated and DMA.RX-channel starts reading BURST_SPI bytes from RX.FIFO. At the same time, the reception from the MISO is continues.
And, when the first byte from the RX.FIFO was read, the trigger of DMA.RX-event is cleared.
If at that moment was received the new byte to the RX.FIFO is finished, is a new DMA-event is generated (although the RX.FIFO still has too few bytes for the 2-nd burst (FIFO contains only BURST_SPI + 1 bytes)).
Then - the reading from RX.FIFO of 1-st burst is finishes and begins reads the 2-nd burst (according to the second RX.DMA-event). Although data for the second burst is not sufficient.
At this point, an underflow occurs.
How to solve this problem?
I want to start the transfer of the data block once and at the end of the transmission of the whole block get a single interrupt about the completion of the entire transmission.
Maybe I did not consider something or incorrectly programmed the configuration of the USIC.SSC or GPDMA?
Thank you in advance for your help. Show Less
I am using USIC in SSC-mode over DMA.
word size: 8bit;
mode: singe-SPI in master-mode;
I program two DMA channels (receive and transmit) for service of SPI. DMA works with the burst size: BURST_SPI == 4 (GPDMA_CH.CTLL.MSIZE == BURST_SPI).
USIC.SSC FIFO size == 16.
RBCTR.LIMIT = BURST_SPI-1; RBCTR.SRBTM == 0; RBCTR.SRBTEN == 0; RBCTR.RNM == 0; RBCTR.LOF == 1; RBCTR.SRBIEN == 1; RBCTR.RBERIEN == 1.
TBCTR.LIMIT = BURST_SPI; TBCTR.STBTM == 0; TBCTR.STBTEN == 0; TBCTR.LOF == 0; TBCTR.STBIEN == 1; TBCTR.TBERIEN == 1.
I set the priority of the DMA.TX-channel to be lower than the priority DMA.RX-channel (GPDMA_CH.CFGL.CH_PRIOR).
I enabled interrupt from RX-DMA-channel (GPDMA.MASK.TFR) after completing transfer entire block.
I pass a 16-bytes block to the SPI.
If SCLK SPI was <= SYSTEM_CLK/4 - all ok - I received single interrupt, no troubles, all data transmitted/received correctly.
If SCLK SPI was == SYSTEM_CLK/2 - in this case, I get the error state "reading an empty receive buffer" (USIC.TRBSR.RBERI == 1). And I recives invalid data (duplicated bytes).
Trying to correct this error, I reduce the value: TBCTR.LIMIT = 1. This underflow error now occurs less often, but it still happens (not with a block size of 16 bytes, but starting with about ~ 1024 bytes and bigger).
I think the scenario for occuring the error is (for TBCTR.LIMIT = 1):
TX.FIFO RX.FIFO
0 0 ;DMA.TX writes BURST_SPI bytes to TX.FIFO (1-st burst)
4 0
3 0 ;TX.FIFO -> TX.SHIFT register (1-st byte)
3 1 ;was transmitted/received last bit of 1-st byte
2 1 ;TX.FIFO -> TX.SHIFT register (2-nd byte)
2 2 ;was transmitted/received last bit of 2-nd byte
1 2 ;TX.FIFO -> TX.SHIFT register (3-rd byte)
1 3 ;was transmitted/received last bit of 3-rd byte
0 3 ;TX.FIFO -> TX.SHIFT register (4-th byte); DMA.TX event -> DMA.TX writes new BURST_SPI bytes to TX.FIFO (2-nd burst)
4 3
4 4 ;was transmitted/received last bit of 4-th byte;
At this point, the event DMA.RX is generated and DMA.RX-channel starts reading BURST_SPI bytes from RX.FIFO. At the same time, the reception from the MISO is continues.
And, when the first byte from the RX.FIFO was read, the trigger of DMA.RX-event is cleared.
If at that moment was received the new byte to the RX.FIFO is finished, is a new DMA-event is generated (although the RX.FIFO still has too few bytes for the 2-nd burst (FIFO contains only BURST_SPI + 1 bytes)).
Then - the reading from RX.FIFO of 1-st burst is finishes and begins reads the 2-nd burst (according to the second RX.DMA-event). Although data for the second burst is not sufficient.
At this point, an underflow occurs.
How to solve this problem?
I want to start the transfer of the data block once and at the end of the transmission of the whole block get a single interrupt about the completion of the entire transmission.
Maybe I did not consider something or incorrectly programmed the configuration of the USIC.SSC or GPDMA?
Thank you in advance for your help. Show Less
XMC™
Hi all,I am confused as to what "bidirectional endpoint" in USB module means. Is it (a) an endpoint that acts as IN and OUT endpoint at the same time;...
Show More
Hi all,
I am confused as to what "bidirectional endpoint" in USB module means. Is it
or
It looks to me like it's the latter case, but can anybody confirm that for me, please?
Thanks so much!
Andrey Show Less
I am confused as to what "bidirectional endpoint" in USB module means. Is it
(a) an endpoint that acts as IN and OUT endpoint at the same time;
or
(b) an endpoint that can be configured as either IN or OUT endpoint?
It looks to me like it's the latter case, but can anybody confirm that for me, please?
Thanks so much!
Andrey Show Less
XMC™
Hello Forum-UserIf I understand the EBU correctly it is possible to use a multiplexed device (e.g. a Display with 16Bit - 8080 Interface) with a non m...
Show More
Hello Forum-User
If I understand the EBU correctly it is possible to use a multiplexed device (e.g. a Display with 16Bit - 8080 Interface)
with a non multiplex SRAM on the same External Bus Unit ?
Best regards,
Ebbe Show Less
If I understand the EBU correctly it is possible to use a multiplexed device (e.g. a Display with 16Bit - 8080 Interface)
with a non multiplex SRAM on the same External Bus Unit ?
Best regards,
Ebbe Show Less