XMC™ Forum Discussions
Hello everybody
Application: I am working on an SPI master-slave communication. To save CPU power we use DMA support. The data transfer works correctly. Also when we produce some noise on the hardware lines, the data protocol detects a CRC error corectly. The application runs on an XMC 4500 Relax Kit.
Problem: When we produce noise on the clock line, the slave samples additional data bits. The protocol detects a CRC error but an additional byte is read by the DMA from the receive register and stored in the DMA FIFO. During the next transfer this additional data byte is processed and as a result all following transfers are corrupt. All data bytes are shifted by one byte.
Question: If a CRC error is detected, I want to reset the DMA FIFO before the next transfer is started. Can some body give me a hint, how this can be done, which command can be used?
Thanks for any support
Andreas
Anyone that skim trough this forum can see that one of the THE MAIN PROBLEMs about XMC1000 series mcu's is leaving ASC BSL mode. This is a real headache.
BUT NON OF INFINEON's TOOLS, can do it properly. Not event its flasher.
Memtool maybe used but it cannot be used with scripts so cannot be used besides development. And I saw that is not properly working in so many cases.
Almost all flash operations can easily be done with the tools that are coming with SEGGER's driver. (Except BMI stuff of course.....)
So since this XMCFlasher is not able change BMI from ASC BSL and perform only the operations that also can be done with board's driver's tools, why would anyone use it? Show Less
Hi,
I am using the XMC1300 to control a Boost converter in PCC mode. I have started with the project 'BUCK_PCC_FIX_FQ_EXAMPLE_XMC13' as this uses DAVE apps and makes it easy to validate. I have the control working in open loop, i.e, changing duty changes the output as expected. However, in Closed loop current control, the PWM signals experience false switching at the start of the switching cycle. The control somewhat works at low input voltages but always mis-triggers at higher operating input voltages. Hence, I would like to implement LEB.
I have ticked the blanking option and set the blanking time. I see that there is difference in the CCU4 timer configuration. But this does not make any difference to its performance. I have attached the snapshot of the configuration in Dave and the waveform as seen on the scope.
The inductor current is represented in yellow while the Low side gate voltage is represented in Blue. Switching frequency is 100 kHz.
I do not suppose any hardware modifications are required as the modules are internally connected. Is there something I have missed? Please let me know.
Show Less
To do this, I want to use one channel in compare mode, which will generate the pulse time, and one channel in capture mode, which will capture the rising edge time.
However, I want to do this in single-shot mode and not have the output reset when the timer stops. It appears that if I do this the simple way in edge-aligned mode, and set the compare match register for channel 1 to the length of the output pulse, then the output will reset right after the timer hits the period match, which I don't want.
If I instead make the compare match register a small value and time my pulse to the period match, inverting the output, I won't be able to capture the input edge, because the timer will have already stopped.
I could maybe use center-aligned mode and pre-load a value before starting the timer to be just before the compare match, and make the compare match close to the period match? The manual is a bit vague about how the active/passive rules apply in single-shot mode.
How can I prevent the output changing when the timer stops in single-shot mode, while still being able to generate a short pulse at the start of the timer run? Show Less
After quite some tinkering and many unsuccessful attempts, I created a method for loading firmware through ASC and (more important), enabling SWD when the only J-Link available doesn't support SPD (J-Link EDU Mini).
It's basically a python script that loads a .bin firmware through a cheap serial adapter using ASC protocol. It allows us to send a firmware that sets the BMI register to SWD debugging mode, making it possible to debug and flash with our J-Link EDU Mini.
Everything is on this repository: equipepucpr/xmc_loader: Infineon ASC BSL Script (github.com)
I am using XMCFlasher and XMC1300 bootkit to program XMC1202-0032
I execute the following sequence :
change BMI to SWD0
erase
program with the hex file
reset the power supply
verify
XMCFlasher gives verify successfull, (file checksum is equal with memory checksum)
But if I save the memory content to my PC and compare with the hex file I programmed , they are different.
I run again the verify command on XMCFlasher software
I still get verify successfull Show Less
I have uploaded a hex file into XMC1202-0032, using XMC1300 Bootkit and XMCFlasher.jar 1.1.1 050320181336
After I have programmed the MCU, I dumped the MCU's flash memory back to my PC.
I got a hex file full of AA
:020000041000EA
:10100000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA40
:10101000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA30
:10102000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA20
:10103000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA10
:10104000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00
:10105000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0
:10106000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0
it goes like that all the memory range.
If I remove and insert the bootkit from/into my PC, I dump again the MCU's flash memory back to my PC.
I got this time the hex file which I have uploaded .
Do you know why is this behaviour? Show Less
I have been using the CSG and HRC included in the HRPWM to perform a peak current control. The minimum step using the CSG to reset the PWM output is of 8.3333ns (120MHz clock).
Due to parasitic phenomenos in the current waveform, the PWM is switching between 2 steps with 8.333ns, not 150ps (or multiples of 150ps) which I expected.
So I guess that before using the high resolution path, the direct output of the comparator is clocked with the module clock by the filtering block even when this funtionality is disable (CSGyCC.COFE = 0)
In addition if CSGyCC.COFE = 1 (filtering enable), the minimum clock to consider comparator output stable is 2, so I guess that when the filtering is disable, the comparator output needs to be stable for one module clock step to trigger the comparator to switch, is that right?
Only after that module clock step, I can pass the reset signal to the PWM through the High Resolution Path to include some 150ps steps of delay to the reset signal. Is that right?
Summarizing, ¿Is it possible to have a reset signal for the PWM from the CSG with out any clock? I mean, in an asynchronous way?
¿The only way to add high resolution of my reset signal is adding 150ps steps AFTER the CSG has triggered and been stable for 1 cycle of the module clock?
Due to parasitic phenomenos I will have jumps of 8.3333ns steps and I will no be able to predict what is going on, but using the High Resolution Path I guess I will have the output voltage with High Resolution, adjusting the HRCyCR2.CR2 to have a fine tunning of steady state output voltage, right?
Is this the proper way to use the CSG? Taking into account that it can not generate an asynchronous output signal (only switch after one module clock(8.33ns) been stable)
Thanks and best regards.
Carlos. Show Less
I am using the PMSM_FOC v1.5.8 for XMC1300 to run a PMSM motor. I am using the XMC1300 boot kit with a custom inverter with internal ADC gains for the three phase current sense.
I have measured the parameter by providing a voltage step on the U-V terminals of the motor while leaving the W phase unconnected. This gave me L_equ and R_equ.
I considered
L_motor = L_equ /2
R_motor = R_equ/2
and used these values as the motor parameters for the controller.
The motors spins in the SPEED_CONTROLLED_VF_MET_FOC and goes into FOC closed loop state. In this state the rpm of the motor follows the speed command. However, in the VQ_CONTROLLED_DIRECT_FOC, the motor oscillates about its initial position and I am unable to run the motor. I have referred to the getting started guide for the instructions on tuning the controller.
After a few hours of changing the parameters of the Flux PI loop, I obtained phase currents that look somewhat sinusiodal (under a small load). The image of the currents are attached.
Am I right in understanding that this issue is due to improper tuning of the flux loop?
What can I do to fix the issue?
Thank you Show Less