XMC™ Forum Discussions
A solution to this is toggling the clock 8 times and sending a stop condition. A similar solution is to perform a Nack Read without Start Condition.
The reference manual describes such a procedure in 18.5.4.2 Valid Master Transmit Data Formats in case of a wrong TDF code.
I would like to perform such a Bus Reset on each boot of my XMC4800. I tried with
XMC_I2C_CH_MasterReceiveNack(channel);
XMC_I2C_CH_MasterStop(channel);
after initialization. Unfortunately, in case of a stuck SDA all what happens is a single clock toggle.
I do not even get an i2c event interrupt. So I need to boot the XMC4800 up to eight times to reset the bus.
Is there a clean way to achieve this bus reset on initialization? Or do I need to configure the Pins as GPIO
first and toggle the clock myself before initializing the I2C module? Show Less
Hello,
Question 1.
On the Infineon website, I found below.
https://infineoncommunity.com/2018Mar_GLOB_GATED_DALI_Software_ID941
But Our customer wants DALI IEC 62386-209. Do you have any plans to update this library.
Question 2.
I heard from a customer that the MCU clock accuracy to implement the DALI library should be within 1%.
The XMC1300 is also included as a target device for this library, but the clock accuracy for this device appears to be over 1%.
Can XMC1300 series satisfy the DALI specification?
Show Less
Hi all, I was going through the implementation of the XMCLib PTP functions, and I think I noticed something that might be a bug. The XMC_ETH_MAC_GetPTPTime() function is implemented simply as:
time->nanoseconds = (uint32_t)(eth_mac->regs->SYSTEM_TIME_NANOSECONDS); /* accuracy of 1 ns */
time->seconds = eth_mac->regs->SYSTEM_TIME_SECONDS;
However, it seems like this does not account for the possibility of timer rollover. Consider the following case:
- SYSTEM_TIME_NANOSECONDS is 999999980 and SYSTEM_TIME_SECONDS is 0.
- The first line of the function executes and reads the nanoseconds.
- A PTP timer tick happens and moves time forward 20ns. SYSTEM_TIME_NANOSECONDS is now 0 and SYSTEM_TIME_SECONDS is now 1.
- The second line of the function executes and reads the seconds.
- The time returns as 1s 999999980ns!
So basically, it seems like there's a very small chance that the time will phantom-jump one second into the future for one call to GetPTPTime(). This would be very rare, it would only happen if a seconds tick happened between the two lines of the function, out of all the 144M instructions executed each second. However, I think that this is a real issue and I don't see anything in the current code that would defend against it.
I think that the function should be changed to the following:
void XMC_ETH_MAC_GetPTPTime(XMC_ETH_MAC_t *const eth_mac, XMC_ETH_MAC_TIME_t *const time)
{
XMC_ASSERT("XMC_ETH_MAC_GetPTPTime: eth_mac is invalid", XMC_ETH_MAC_IsValidModule(eth_mac->regs));
do
{
time->nanoseconds = (int32_t)eth_mac->regs->SYSTEM_TIME_NANOSECONDS;
time->seconds = eth_mac->regs->SYSTEM_TIME_SECONDS;
}
// If the time in nanoseconds went down, this means that there was a rollover at some point
// during the read operation. Since we don't know if we read SYSTEM_TIME_SECONDS before or after
// the rollover, we need to retry the read operation.
// Note that since rollovers happen once a second, this can never loop back more than once.
while(time->nanoseconds > (int32_t)eth_mac->regs->SYSTEM_TIME_NANOSECONDS);
}
Using a loop like this is a common solution to this sort of problem, and I've used something very similar to fix this same issue reading linked CCU4 timers.
Show LessI have a DAVE project that I am trying to flash over the air. If I use a Segger debug probe from within the DAVE IDE to flash it, it boots and runs fine. If I power reset without the Segger debug probe attached, it also boots and runs fine. If I use the Infineon supplied XMCLoad over a serial port to flash it, it flashes without error, but won’t boot and run. The .hex file I am flashing using XMCLoad is from the debug build directory of the DAVE project.
I’m not sure if there is some setting in the DAVE IDE that I need to specify in order to get it to flash using XMCLoad correctly or if the problem lies elsewhere. Does anyone have any ideas?
Show LessHello forum,
looking at the XMC4700 Relax Kit (https://www.infineon.com/dgdl/Infineon-Board_User_Manual_XMC4700_XMC4800_Relax_Kit_Series-UM-v01_02-EN.pdf?fileId=5546d46250cc1fdf01513f8e052d07fc), there's a quartz clock generator attached to the ETH PHY chip (p. 18 of 25).
As this RMII PHY requires a clock input: Can it be generated by the XMC4700 or do I need a quartz?
If an internal clock can be used (not sure if fETH is the one?), is it precise enough?
Best regards,
Paul
Show LessHello community,
looking into the DAVE-provided LWIP implementation, there seem to be 3 supported PHYs so far:
- DP83848C Phyter
- KSZ8031RNL
- KSZ8081RNB
I'm trying to build a custom PCB, but I fear getting burnt by not being able to to implement the PHY correctly.
Are there more implementations available like Microchip LAN 8740?
Best regards,
Paul
Show LessIs there a single MO entry to read for the RxFIFO? Seems like I have to walk each MO that is being used for the FIFO but this seems odd to do and I am probably doing it wrong.
Thanks Show Less
Hello,
I have a question regarding flash write / erase operations.
In the documentation, it says that when the flash is in command mode, read access to this flash bank are refused with a bus error (See section 8.4.6).
Does this mean that before a write operation to flash we should block any interrupts which can change potentially change the execution flow and trigger a new instruction read from the flash memory?
Thanks.
Show LessI have ruled out cabling problems and similar hardware problems since it work perfect with three devices, different devices, different connections and different cables but problem start only then more devices are added. It seems even though message does not arrive back at master, also checked with wireshark values are written to fifth device then checking with debugger.
Then adding more than three devices some error counters increase. I have measured message with oscilloscope it seems device closest to master send message back to master so it seems it get destroyed in some way. Only clue I have is port two is physically connected even though it is not implemented in XMC4800? Anyone else have suggestions? Or got it to work with more devices?
Circuit boards should be ready for small series production, actually already made a few though I have some work left with the enclosure. Show Less
Processor card: KIT_XMC4400_DC_V1
Drive board: EVAL-M5-IMZ120R-SIC board.
Question: How to set absolute current limit in software for I-V, I-U and I-W?
Problem: we can drive the motor for 2s. However, the current of I-V/U/W keep increasing. then trigger the CTRAP ..
Thanks
Show Less