XMC™ Forum Discussions
I'm utilizing Dave apps to set up the XMC1400 as an SPI_Master with half-duplex communication. However, I'm encountering an issue where the microcontroller maintains the data pin at a high state when the master isn't transmitting, resulting in collisions when attempting to receive data from the slave, as depicted in the figure below. How can I resolve this problem?
Show Less
Hello,
I am using XMC4500 relax kit to program and run MIT Cheetah motor AK80-9. The code is correct enough that the motor shows the green light when but when I try to debug and run the motor doesnot respond correctly. from 20 tries motor might respond once or twice and shows the green light. I have checked the c/c++ settings, motor CAN id.
Am i missing something or what could have gone wrong.
I am using DAVE 4.4.2
The code:
Hello, everyone!
As the title suggests, when compiling with Dave 4.5 today, the .bin file generated is larger than the .hex file, what could be the reason? Is there a setting somewhere that isn't set?
Information compiled in .bin format, using release mode compilation
.hex compile-time information, compiled using debug mode
smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/XMC/Dave%E7%BC%96%E8%AF%91%E5%90%8E%E7%9A%84bin%E6%A0%BC%E5%BC%8F%E6%96%87%E4%BB%B6%E5%A4%A7%E4%BA%8Ehex%E6%A0%BC%E5%BC%8F%E6%96%87%E4%BB%B6/td-p/731940
Show LessI'm attempting to utilize half-duplex SPI communication with an XMC1400 acting as the master. I've configured the SPI pins as push-pull using DAVE apps, and here's the corresponding code:
XMC_GPIO_SetMode(MOSI_Port, MOSI_Pin, XMC_GPIO_MODE_OUTPUT_PUSH_PULL_ALT9); SPI_MASTER_Transmit(&SPI_MASTER_0, arr, sizeof(arr));
while (SPI_MASTER_IsTxBusy(&SPI_MASTER_0));
for(int i = 0; i < 20; i++);
XMC_GPIO_SetMode(MOSI_Port, MOSI_Pin, XMC_GPIO_MODE_INPUT_TRISTATE);
SPI_MASTER_Receive(&SPI_MASTER_0, &Read_Data, 1);
while (SPI_MASTER_IsRxBusy(&SPI_MASTER_0));
Although the data is transmitted correctly from the slave and seen on the data line using oscilloscope, the value returned by the SPI_MASTER_Receive
function, Read_Data
, always consists of all ones.
As a temporary workaround, I've configured the XMC1400 as full-duplex and connected the MOSI to the MISO pin together.
Now, the question is whether the SPI_MASTER_Receive
function can function properly when the XMC1400 is configured as a half-duplex SPI master.
Hello,
By working though the XMC4500 Reference Manual, I found, that the UCB0 memory seems to be overlapping with the default vector table location.
Basically at system reset, and in normal Boot mode, the controller starts excution at the base of the flash. When I want to use UCB0 for example for flash protection, this data is overlapping with my vector table.
Links to Reference Manual.
XMC4500 Refenrece Manual Normal Boot Mode start location
Do I missunderstand this somehow?
Show LessI'm attempting to utilize the XMC_Debug message feature on the XMC1400 boot kit. Despite exhausting all the solutions provided in various discussion threads on this issue, none seem to resolve it.
Here's what I've tried:
- Added
XMC_DEBUG_ENABLE
to the defined symbols of the arm-GCC C compiler. - Included the flag
--specs=rdimon.specs
in the linker settings. - Imported the function
initialise_monitor_handles()
usingextern void initialise_monitor_handles(void);
. - Called
initialise_monitor_handles()
before utilizingXMC_Debug
. - Enabled semihosting and GDB Client.
However, I consistently encounter the following errors:
No source available for "_swistat() at 0x10001f4a"
No source available for "_fstat() at 0x10001f7a"
No source available for "_fstat_r() at 0x10001c0a"
Shouldn't printing a simple debug message be straightforward without consuming countless hours searching for a solution? I'm sharing my project in the attachment in hopes that someone can provide a definitive solution to this problem.
Show LessThe following problem occurred during a recent burn-in with the 1404 :
For the new 1404 chip, itself is in ASC_BSL mode, with USB to 232 from the 232 port or serial port to TTL from the SWD port using the infineon memtool can be burned directly, but some of the new chip burned in this way can not be burned (test 10, 2 two burned failures), you need to use other burner to modify the mode and then burned. Such as: need to use DAVE to change the mode (need to repeatedly power on the success rate is not particularly high), or use Weifu burner (high success rate but need Weifu burner)
smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/XMC/1404-%E7%83%A7%E5%85%A5iSSUE/td-p/731664
Show Lesshi
we can not use https://github.com/Infineon/mtb-wifi-bluetooth-tester to download code
and we can find it support (KIT_XMC72_EVK_MUR_43439M2) in the document
but we can not build code
command
./project-creator-cli.exe --board-id KIT_XMC72_EVK_MUR_43439M2 --app-id mtb-wifi-bluetooth-tester --user-app-name Wi-Fi_Bluetooth_tester --target-dir "C:/mtw/"
message :
The "mtb-wifi-bluetooth-tester" application is not compatible with the "KIT_XMC72_EVK_MUR_43439M2" BSP.
ERROR:Failed to create a new project creation data model.
james
Show Less
1. Is there any use, incremental UVW or incremental ABZ and PWM absolute encoder. Routine code to control Brushless DC (BLDC)?
2. I'm currently using the XMC4800
smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/XMC/%E8%AF%B7%E9%97%AE%E6%9C%89%E6%B2%A1%E6%9C%89%E4%BD%BF%E7%94%A8-%E5%A2%9E%E9%87%8FUVW%E6%88%96%E8%80%85%E5%A2%9E%E9%87%8FABZ%E5%92%8CPWM%E7%BB%9D%E5%AF%B9%E5%80%BC%E7%BC%96%E7%A0%81%E5%99%A8-%E6%8E%A7%E5%88%B6%E6%97%A0%E5%88%B7%E7%9B%B4%E6%B5%81%E7%94%B5-BLDC-%E7%9A%84%E4%BE%8B%E7%A8%8B%E4%BB%A3%E7%A0%81/td-p/732192
Show Lesssmartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/XMC/%E7%94%B5%E6%9C%BA%E6%8E%A7%E5%88%B6%E4%BC%98%E5%8A%BF/td-p/731828
Show Less