XMC™ Forum Discussions
XMC™
Hello forum members and all of you first a nice St. Nicholas day.The below command is out from the above mentioned c-file/****************************...
Show More
Hello forum members and all of you first a nice St. Nicholas day.
The below command is out from the above mentioned c-file
In the demo from Infineon the PLL Setup was realized with the Parameter
If I made the calculation I also get the 288 MHz for the PLL frequency
But in the Manual XMC4000 Family V1.0 2016-01 in the Cappter 3.3.4 Phase Locked Loop (PLL) Characteristics
The MAX. PLL base frequency is 140 MHz is this OK, in my opinion no.
But also in the DAVE app and in the examples you can set this frequency or I miss something
Thanks for your Help
With best regards
EbbeSand Show Less
The below command is out from the above mentioned c-file
/*******************************************************************************
* Default clock initialization
* fPLL = 288MHz => fSYS = 144MHz => fCPU = 144MHz
* => fPB = 144MHz
* => fCCU = 144MHz
* => fETH = 72MHz
* => fUSB = 48MHz
* => fEBU = 72MHz
*
* fUSBPLL Disabled, only enabled if SCU_CLK_USBCLKCR_USBSEL_USBPLL is selected
*
* fOFI = 24MHz => fWDT = 24MHz
*******************************************************************************/
In the demo from Infineon the PLL Setup was realized with the Parameter
#elif OSCHP_FREQUENCY == 12000000U
#define PLL_PDIV (1U)
#define PLL_NDIV (47U)
#define PLL_K2DIV (0U)
If I made the calculation I also get the 288 MHz for the PLL frequency
But in the Manual XMC4000 Family V1.0 2016-01 in the Cappter 3.3.4 Phase Locked Loop (PLL) Characteristics
The MAX. PLL base frequency is 140 MHz is this OK, in my opinion no.
But also in the DAVE app and in the examples you can set this frequency or I miss something
Thanks for your Help
With best regards
EbbeSand Show Less
XMC™
Hi,I'm currently trying to figure out how things work, and I came across a question for which I couldn't find an answer (yet).When I'm adjusting the a...
Show More
Hi,
I'm currently trying to figure out how things work, and I came across a question for which I couldn't find an answer (yet).
When I'm adjusting the area of the Flash in the linker script, (e.g. because I want to use a Bootloader) the program will still run on the XMC.
In the "C-Start and Device Initialization" Guide, it states:
I was at first wondering how the on-chip firmware would find out where I'd put the Vector table, but actually the Vector table is stored both at the actual start of Flash and at my shifted start of flash.
However, when I open the hex file, all the data is located at my shifted start of Flash.
Can anyone explain to me why this happens?
cheers,
Matthias Show Less
I'm currently trying to figure out how things work, and I came across a question for which I couldn't find an answer (yet).
When I'm adjusting the area of the Flash in the linker script, (e.g. because I want to use a Bootloader) the program will still run on the XMC.
In the "C-Start and Device Initialization" Guide, it states:
Normal Boot Mode is a commonly deployed boot-mode. On execution, the on-chip firmware reads the
user application vector table, typically placed at the start of the Flash area. It extracts the start
address of the C-Start routines and then cedes control to the reset handler routine.
I was at first wondering how the on-chip firmware would find out where I'd put the Vector table, but actually the Vector table is stored both at the actual start of Flash and at my shifted start of flash.
However, when I open the hex file, all the data is located at my shifted start of Flash.
Can anyone explain to me why this happens?
cheers,
Matthias Show Less
XMC™
I'm looking to use two analog inputs to watch quadrature signals, setting a threshold, ideally with hysteresis, and feeding those now digital signals ...
Show More
I'm looking to use two analog inputs to watch quadrature signals, setting a threshold, ideally with hysteresis, and feeding those now digital signals to the quadrature decoder hardware.
With two ADC cores and POSIF's VADC0.CBFLOUT, it looks like this should be possible.
I'm looking at the ADC registers in the reference manual and have not gotten to the bottom of this yet.
Has anyone else tried this?
Does anyone know if XMClib supports configuring this or am I stuck doing this directly with registers? Show Less
With two ADC cores and POSIF's VADC0.CBFLOUT, it looks like this should be possible.
I'm looking at the ADC registers in the reference manual and have not gotten to the bottom of this yet.
Has anyone else tried this?
Does anyone know if XMClib supports configuring this or am I stuck doing this directly with registers? Show Less
XMC™
Hello,We are using an XMC4500 in a safety critical application.We have an external Watchdog connected to PORST pin which will pull PORST down and perf...
Show More
Hello,
We are using an XMC4500 in a safety critical application.
We have an external Watchdog connected to PORST pin which will pull PORST down
and perform a PORST reset if we do not service it periodically.
So far so good...
Now we need to test the Watchdog hardware at power on to make sure it works.
To do that, we store a flag in some non volatile RAM, I was hopping to use GPR registers.
But they are cleared by PORST.
It is therefore impossible to differentiate a PORST from a Watchdog test puling down PORST pin.
Does someone suggest me another Non volatile memory area that would persist to PORST ?
ABM?
Hibernate mode registers ?
Has someone some experience or an idea on how to test an external WD circuit.
Thanks a lot for your suggestions or ideas.
Jorge Show Less
We are using an XMC4500 in a safety critical application.
We have an external Watchdog connected to PORST pin which will pull PORST down
and perform a PORST reset if we do not service it periodically.
So far so good...
Now we need to test the Watchdog hardware at power on to make sure it works.
To do that, we store a flag in some non volatile RAM, I was hopping to use GPR registers.
But they are cleared by PORST.
It is therefore impossible to differentiate a PORST from a Watchdog test puling down PORST pin.
Does someone suggest me another Non volatile memory area that would persist to PORST ?
ABM?
Hibernate mode registers ?
Has someone some experience or an idea on how to test an external WD circuit.
Thanks a lot for your suggestions or ideas.
Jorge Show Less
XMC™
I've been working on a flash programm on an XMC4700/4800 relax kit v1. Mostly a bit of reading and writing.Originally i was convinced i had written on...
Show More
I've been working on a flash programm on an XMC4700/4800 relax kit v1. Mostly a bit of reading and writing.
Originally i was convinced i had written onto an illegal address, but i checked again and it turned out to be wrong.
The connection to the J-Link does work, but flashing or debugging results in below errors. Did i brick my board? If it is unrecoverable, how do i prevent that from happening again?
I get the error messages: "No source available for "0x0"" and:
Error in final launch sequence
Failed to execute MI command:
tbreak main
Error message from debugger back end:
Cannot access memory at address 0x80007ea
Failed to execute MI command:
tbreak main
Error message from debugger back end:
Cannot access memory at address 0x80007ea
Cannot access memory at address 0x80007ea
From what i have extracted from the datasheet it is in the section "Code" / "reserved" (0x00004000 ... 0x07FFFFFF)
However i was working on the uncached flash, with base adresses on 0x0C000000 ... 0x0C1FFFFF. An overflow or a simple miss assignment doesn't seem likely. Show Less
Originally i was convinced i had written onto an illegal address, but i checked again and it turned out to be wrong.
The connection to the J-Link does work, but flashing or debugging results in below errors. Did i brick my board? If it is unrecoverable, how do i prevent that from happening again?
I get the error messages: "No source available for "0x0"" and:
Error in final launch sequence
Failed to execute MI command:
tbreak main
Error message from debugger back end:
Cannot access memory at address 0x80007ea
Failed to execute MI command:
tbreak main
Error message from debugger back end:
Cannot access memory at address 0x80007ea
Cannot access memory at address 0x80007ea
From what i have extracted from the datasheet it is in the section "Code" / "reserved" (0x00004000 ... 0x07FFFFFF)
However i was working on the uncached flash, with base adresses on 0x0C000000 ... 0x0C1FFFFF. An overflow or a simple miss assignment doesn't seem likely. Show Less
XMC™
Hi. I am currently studying using the XMC1400.In the meantime, you will see a code listing the GPIO settings. I know a little bit about what the code ...
Show More
Hi. I am currently studying using the XMC1400.
In the meantime, you will see a code listing the GPIO settings. I know a little bit about what the code does. However, I do not understand why I wrote code this way when I set up a port or device connection.
And where can I find the value of "pin"?
The GPIO setup code is directly below.
void XMC_GPIO_Init(XMC_GPIO_PORT_t *const port, const uint8_t pin, const XMC_GPIO_CONFIG_t *const config)
{
XMC_ASSERT("XMC_GPIO_Init: Invalid port", XMC_GPIO_CHECK_PORT(port));
XMC_ASSERT("XMC_GPIO_Init: Invalid mode", XMC_GPIO_IsModeValid(config->mode));
XMC_ASSERT("XMC_GPIO_Init: Invalid input hysteresis", XMC_GPIO_CHECK_INPUT_HYSTERESIS(config->input_hysteresis));
/* Switch to input */
port->IOCR[pin >> 2U] &= ~(uint32_t)((uint32_t)PORT_IOCR_PC_Msk << (PORT_IOCR_PC_Size * (pin & 0x3U)));
/* HW port control is disabled */
port->HWSEL &= ~(uint32_t)((uint32_t)PORT_HWSEL_Msk << ((uint32_t)pin << 1U));
/* Set input hysteresis */
port->PHCR[(uint32_t)pin >> 3U] &= ~(uint32_t)((uint32_t)PORT_PHCR_Msk << ((uint32_t)PORT_PHCR_Size * ((uint32_t)pin & 0x7U)));
port->PHCR[(uint32_t)pin >> 3U] |= (uint32_t)config->input_hysteresis << ((uint32_t)PORT_PHCR_Size * ((uint32_t)pin & 0x7U));
/* Enable digital input */
if (XMC_GPIO_CHECK_ANALOG_PORT(port))
{
port->PDISC &= ~(uint32_t)((uint32_t)0x1U << pin);
}
/* Set output level */
port->OMR = (uint32_t)config->output_level << pin;
/* Set mode */
port->IOCR[pin >> 2U] |= (uint32_t)config->mode << (PORT_IOCR_PC_Size * (pin & 0x3U));
} Show Less
In the meantime, you will see a code listing the GPIO settings. I know a little bit about what the code does. However, I do not understand why I wrote code this way when I set up a port or device connection.
And where can I find the value of "pin"?
The GPIO setup code is directly below.
void XMC_GPIO_Init(XMC_GPIO_PORT_t *const port, const uint8_t pin, const XMC_GPIO_CONFIG_t *const config)
{
XMC_ASSERT("XMC_GPIO_Init: Invalid port", XMC_GPIO_CHECK_PORT(port));
XMC_ASSERT("XMC_GPIO_Init: Invalid mode", XMC_GPIO_IsModeValid(config->mode));
XMC_ASSERT("XMC_GPIO_Init: Invalid input hysteresis", XMC_GPIO_CHECK_INPUT_HYSTERESIS(config->input_hysteresis));
/* Switch to input */
port->IOCR[pin >> 2U] &= ~(uint32_t)((uint32_t)PORT_IOCR_PC_Msk << (PORT_IOCR_PC_Size * (pin & 0x3U)));
/* HW port control is disabled */
port->HWSEL &= ~(uint32_t)((uint32_t)PORT_HWSEL_Msk << ((uint32_t)pin << 1U));
/* Set input hysteresis */
port->PHCR[(uint32_t)pin >> 3U] &= ~(uint32_t)((uint32_t)PORT_PHCR_Msk << ((uint32_t)PORT_PHCR_Size * ((uint32_t)pin & 0x7U)));
port->PHCR[(uint32_t)pin >> 3U] |= (uint32_t)config->input_hysteresis << ((uint32_t)PORT_PHCR_Size * ((uint32_t)pin & 0x7U));
/* Enable digital input */
if (XMC_GPIO_CHECK_ANALOG_PORT(port))
{
port->PDISC &= ~(uint32_t)((uint32_t)0x1U << pin);
}
/* Set output level */
port->OMR = (uint32_t)config->output_level << pin;
/* Set mode */
port->IOCR[pin >> 2U] |= (uint32_t)config->mode << (PORT_IOCR_PC_Size * (pin & 0x3U));
} Show Less
XMC™
Hello to administrator of infineon: recently,i use XMC4500 on a board designed by ourselves. I can download my program based on your R...
Show More
Hello to administrator of infineon:
recently,i use XMC4500 on a board designed by ourselves.
I can download my program based on your RTOS system code and it runs correctly .
however when i power up without connecting the ethernet cable ,the program seems choked in somewhere,
because the system cannot light up even a LED light on the board or cannot ping through by computer.
Well, i have been testing for a week by simple split the FTP SERVER APP into two parts FAFT_INIT & ETH_LWIP _INIT,
and it doesn't work, personally i think there should be deep problem with ETH_LWIP,
since it is the key to initialize the system configuration correctly.
Crucially, after a hardware reset signal to the MCU, everything is back to normal !!!
Frustrate by this problem, my project hit a bottleneck.
Sincerely, i hope someone could give some advice or discussion for me.
My project code partly and my DAVE configuration paste below.
Best regards,
DBking Show Less
recently,i use XMC4500 on a board designed by ourselves.
I can download my program based on your RTOS system code and it runs correctly .
however when i power up without connecting the ethernet cable ,the program seems choked in somewhere,
because the system cannot light up even a LED light on the board or cannot ping through by computer.
Well, i have been testing for a week by simple split the FTP SERVER APP into two parts FAFT_INIT & ETH_LWIP _INIT,
and it doesn't work, personally i think there should be deep problem with ETH_LWIP,
since it is the key to initialize the system configuration correctly.
Crucially, after a hardware reset signal to the MCU, everything is back to normal !!!
Frustrate by this problem, my project hit a bottleneck.
Sincerely, i hope someone could give some advice or discussion for me.
My project code partly and my DAVE configuration paste below.
Best regards,
DBking Show Less
XMC™
It looks like there is a bug in the HW_Init code in "Dave/Generated/ECAT_SSC/xmc_eschw.c"The gpio_config and port_control structures are not being ful...
Show More
It looks like there is a bug in the HW_Init code in "Dave/Generated/ECAT_SSC/xmc_eschw.c"
The gpio_config and port_control structures are not being fully initialized. This results in the gpio_config.output_level variable being assigned a random stack value.
When gpio_config.output_level is used to initialize the ECAT gpios in XMC_GPIO_Init() it assigns garbage stack values into the OMR register.
port->OMR = (uint32_t)config->output_level << pin;
UINT16 HW_Init(void)
{
uint8_t i;
XMC_ECAT_PORT_CTRL_t port_control;
XMC_GPIO_CONFIG_t gpio_config;
memset(&port_control, 0, sizeof(port_control)); // <-- add this line
memset(&gpio_config, 0, sizeof(gpio_config)); // <-- add this line
============================
DAVE Version: 4.4.2
ECAT_SSC APP Version: 4.0.22 Show Less
The gpio_config and port_control structures are not being fully initialized. This results in the gpio_config.output_level variable being assigned a random stack value.
When gpio_config.output_level is used to initialize the ECAT gpios in XMC_GPIO_Init() it assigns garbage stack values into the OMR register.
port->OMR = (uint32_t)config->output_level << pin;
UINT16 HW_Init(void)
{
uint8_t i;
XMC_ECAT_PORT_CTRL_t port_control;
XMC_GPIO_CONFIG_t gpio_config;
memset(&port_control, 0, sizeof(port_control)); // <-- add this line
memset(&gpio_config, 0, sizeof(gpio_config)); // <-- add this line
============================
DAVE Version: 4.4.2
ECAT_SSC APP Version: 4.0.22 Show Less
XMC™
XMC™
Hardware Setup:Infineon Iridium SLB 9670 TPM 2.0 interface with NXP MPC5748G via SPISoftware Setup: S32 IDE with FreeRTOS we have connected NXP MPC574...
Show More
Hardware Setup:
Infineon Iridium SLB 9670 TPM 2.0 interface with NXP MPC5748G via SPI
Software Setup:
S32 IDE with FreeRTOS
we have connected NXP MPC5748G as a master and Iridium SLB 9670 TPM 2.0 as a slave.
Connection are as below mentioned:
NXP MPC5748G Iridium SLB 9670 PIN
MOSI 19
MISO 21
CLK 23
Chip selc 26
Vcc (3.3 V) 1
GND 6
SPI specification:
1. Baudrate 5000000
2. Mode 0
But we are facing following problems.
1. We are not getting response as TPM_ACCESS_VALID(0x80) from SLB9670 in Startup-wait implementation
2. Not getting vendor id for command TPM_DID_VID( 83 D4 0F 00 00 00 00 00 )
Could you please share your comment on the above issues.
Thanks in advance. Show Less
Infineon Iridium SLB 9670 TPM 2.0 interface with NXP MPC5748G via SPI
Software Setup:
S32 IDE with FreeRTOS
we have connected NXP MPC5748G as a master and Iridium SLB 9670 TPM 2.0 as a slave.
Connection are as below mentioned:
NXP MPC5748G Iridium SLB 9670 PIN
MOSI 19
MISO 21
CLK 23
Chip selc 26
Vcc (3.3 V) 1
GND 6
SPI specification:
1. Baudrate 5000000
2. Mode 0
But we are facing following problems.
1. We are not getting response as TPM_ACCESS_VALID(0x80) from SLB9670 in Startup-wait implementation
2. Not getting vendor id for command TPM_DID_VID( 83 D4 0F 00 00 00 00 00 )
Could you please share your comment on the above issues.
Thanks in advance. Show Less