Quantcast
Channel: Infineon Forums
Viewing all 9892 articles
Browse latest View live

QR Buck LED Driver XMC14 demo doesn't switch on ZCD

$
0
0
We are experimenting with the QR Buck LED Driver XMC14 demo (VD_QR_BUCK_LED_DRIVER_01). The demo does not appear to enter into quasi-resonant switching as designed.

Checking the hardware connections it appears that there is a good signal at the ZCD pin. However, it does not appear to trigger next switching cycle.

Instead the switching cycle is triggered by timeout of maximum off-time.

Can anyone from Infineon comment on this issue? Is the QR Buck LED Driver Example code fully functional?

NVIC001 Migration to INTERRUPT App in Dave 4

$
0
0
I am moving a project from Dave 3 to Dave 4 and I am having an issue when remodelling the behaviour of the NVIC001 app of Dave 3 to the INTERRUPT App of Dave 4.
In Dave 3 the generated source code of the NVIC001 app implemented the IRQ handler and called a user defined function. I have used this functionality to call a method which is part of a library:
Code:

//in NVIC001.c :
void IRQ_Hdlr_57(void)
{
  /* <<<DD_NVIC001_non_API_1>>>*/
  DBG002_FUNCTION_ENTRY(APP_GID,NVIC001_FUNC_ENTRY);         
  /* Calling user defined Event handler*/
  MyLibraryFunction();
  DBG002_FUNCTION_EXIT(APP_GID,NVIC001_FUNC_EXIT);
}

The new INTERRUPT app copies the name of the user defined function and uses it in the context of a macro. Calling a function of a prebuilt library is not possible anymore without using a wrapper routine as the IRQ handler may vary in the several projects which use the library:
Code:

//in interrupt_extern.h :
#define MyLibraryFunction IRQ_Hdlr_57

I would like to suggest a modification of the INTERRUPT app so that using a macro for mapping the user interrupt handler is avoided. If the generated source code of NVIC001 is reused, there will be another advantage: the users will get errors during compile time when they forget to implement the user interrupt handler instead of wondering why the misspelled/excluded from build/... function is not entered.

Hightec project for the TriBoard TC234

$
0
0
Hi.
do you know how generat hex file in the the HighTec compiler?
Thanks.

DAP Miniwiggler V3 JTAG connector

$
0
0
Hi.
I use the miniWiggler JDS circuit for debugging of TC1724. this circuit are in “TriBoard TC1724 Hardware Manual” document(page 8-5).I don’t know how to connect JTAG output pins of this circuit to my TC1724?
I can connect to my board in ASC Bootloader mode in infineon Memtool by this circuit but i want use the JTAG interface to debugging.The DAS can't identify my wiggler!there is eeprom in miniwiggler JDS circuit.do need unic code for this IC?
Thank you.
Attachment 2930
?????

Dave applications hangs in bool XMC_SCU_CLOCK_IsLowPowerOscillatorStable(void)

$
0
0
Hello Dave team,

I have an issue were the J-Link Debug session fails to move pass
this function:

bool XMC_SCU_CLOCK_IsLowPowerOscillatorStable(void)
{
return ((SCU_HIBERNATE->HDSTAT & SCU_HIBERNATE_HDSTAT_ULPWDG_Msk) == 0UL);
}

Stays there indefinitely and cant debug program.

The program will run if I reset the XMC4700 Relax Kit

Any Ideas as to why this would happen?

Bootloader for XMC1400 and XMC4700

$
0
0
Today version 1.3.2 of the OpenBLT open source bootloader was released. It can be downloaded from: https://www.feaser.com/openblt/doku.php?id=download.

It now includes demo programs for the XMC1400 (Boot Kit) and the XMC4700 (Relax Kit) that can perform firmware updates via RS232 and the CAN bus.
They are pre-configured for the Dave 4 development environment and the IAR Embedded Workbench. I think this should cover everyone's needs.

Support for firmware updates from SD-card, via TCP/IP, or via USB is planned for later this year on the XMC4700 Relax Kit.

Feedback and ideas are always welcome!

-Frank

XMC1200 What is the "FF" block on GPIO Input channel

$
0
0
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?

Attachment 2931
?????

dave bmi get set XMC1100

$
0
0
We have been using XMC1300 J-Link Lite Bootkit to Get/Set BMI, Program and Debug XMC1302. We have ordered four new XMC1300 J-Link Lite Bootkits last month. With our old bootkit (the same model but previously ordered than these four), we were able to do all these three operations. But I am afraid to let you know that we are not able to Get/Set BMI from these new Kits though we are able to program and debug. The error states that we have to update the driver, we also did that. Now the driver is up-to-date. FYI, this problem lies in both DAVE 3.1.8 and DAVE 4.1.2.We are quite an old customer of Segger and Infineon, so I kindly request you to help us resolve this issue as soon as possible.

Thanks in advance.

Shaunak Agastya Vyas

Impossible to set BMI

$
0
0
We have been using XMC1300 J-Link Lite Bootkit to Get/Set BMI, Program and Debug XMC1302. We have ordered four new XMC1300 J-Link Lite Bootkits last month. With our old bootkit (the same model but previously ordered than these four), we were able to do all these three operations. But I am afraid to let you know that we are not able to Get/Set BMI from these new Kits though we are able to program and debug. The error states that we have to update the driver, we also did that. Now the driver is up-to-date. FYI, this problem lies in both DAVE 3.1.8 and DAVE 4.1.2.We are quite an old customer of Segger and Infineon, so I kindly request you to help us resolve this issue as soon as possible.

Thanks in advance.

Shaunak Agastya Vyas

April 21, 2017: New Release of DAVE™ APPs, XMC Lib and other Libraries

$
0
0
Hello,

after downloading and installing this update, i couldn't upgrade my XMC4400 project to this new release.
The upgrade stops with the solver error:
"Solver Error while setting the GUI value to APP!"
I am using Dave-4.3.2-64Bit with APP version dated 2016-09-26.
Please see the attached DAVE CE Project Migration Report and the export of the Dave Error Log for more details.
How can i solve this issue?

Best regards
?????

Migration from XMC4500 to XMC4700

$
0
0
Hi Ingo and Jesus,

Ingo, thank you for your response.

Quote:

Do you also use 16Bit demultiplexed Bus ?
No, we only use multiiplexed bus including A16 and A17 to have 18 address lanes.

Quote:

It is also very difficult to get a mini project for Jesus so that he can repoduce it because of the behaviour described above.
We managed to get a minimal project that shows the described behaviour.

Jesus, I attached the project to this post, named "zebu.zip".
The project shows a bus fault after about two seconds on our hardware.
If you could use one of our test-Hardware stations let me know, i think we could easily send you one.

We tried many different configurations on different Projects.
Let me sum up our findings during testing:
- We tested two configurations,
Config 1: Setting the input clock to the EBU to synchronous mode to the AHB. The config is provided in the attached file "Zebu/cfg/ebu_cfg47.h"
Config 2: Setting the input clock to the EBU to asynchronous mode to the AHB with Setting the EBUDIV divider in SCU_CLK.EBUDIV. This config is in the file zebu/cfg/ebu_cfg47_good.h.

Config 1: The EBU_CLK equals the clock of the AHB, we tried 144 MHz and 120 MHz. We tried many changes with the remining timing parameters. We verified these on the oscilloscope and read and write accesses worked without errors but we had Bus Fault Exceptions regardless of the exact Settings.
Config 2: The EBU_CLK is derived from the PLL with the divider SCU_CLK.EBUDIV. We set this divider with respect to fCPU either to 144 MHz: 8 or 120 MHz : 6.
We found few bus faults with fCPU = 144 MHz and until now not a single bus fault with fCPU = 120 MHz.

In our understanding, the reasons for the bus faults should not depend on external devices but on the internal AHB-Interface between the EBU and the Bus Matrix, so we tried changing the EBU-Clocking configuration and adapting the external Timings accordingly.

Jesus could you please review our configuration and give a statement to the described, different behaviours between the configurations? Is Config 2 a hundred percent safe with 120 MHz?
The thing is we need a 100% working configuration with no bus faults at all so that we can get to production with the XMC Controller.

We found a similar Problem regarding bus faults on Cortex m cpus, see https://www.lpcware.com/content/foru...cd-display-tft
The solution there seems to be to clock the "EMC", which basically complys with the EBU, with less than the Maximum fCPU clock. This is even stated in the reference Manual of this LPC Controller.
Is there a similar hint for the XMC4700 EBU ?

Thank you for your help

Karl
?????

Not Selected

$
0
0
Hi all,

Has anyone had a problem with transferring a DAVE project from one PC to another, and finding all the pin allocations show as 'Not Selected', on the second PC?

If I transfer the project back, the pin allocations show correctly. In other words, it's a temporary 'no show', rather than a permanent allocation deletion.

I have the latest DAVE, 4.3.2, installed on both PCs, both running Windows 7. The project is using the latest APP etc release, per Georg Huba's recent post, Apr 21st. And the issue occurs regardless of whether I do a direct copy of the entire workspace folder, from one PC to the other (via a zip file, for speed), or use the DAVE import and export facility, selecting all elements.

I don't know if relevant or not, but the first PC has 64-bit Windows, and has 'DAVE-4.3.2-64Bit' installed, and so workspace path stem is C:\Workspaces\DAVE-4.3-64Bit\.
Whereas the second PC has 32-bit Windows, and has 'DAVE-4.3.2' installed, so the workspace path stem is C:\Workspaces\DAVE-4.3\

I tried the transfer back and forth with the second PC stem as-is, and also with -64Bit\ appended, in case made a difference, it didn't.

I've searched on the Forum and google, but couldn't find anything.

It's not a major issue, it just means on the second PC, I can't do any pin re-allocations, or Solver or Generate Code runs..

Best regards,

David King

Green and Yellow

$
0
0
Hi,

About the Relax board EI+EO Broadcom BCM5241XA1KMLG PHYs, I've now been given the full 77-page datasheet.

In the LED section, I can see it says LED1 and LED2 output pin function, is determined by the PHY-sensed state of those pins at power-up reset (POR).

The PHY will sense LED1 and LED2 pins high, courtesy external pull-ups, via R270 and yellow LED to 3V3, and via 2K2 to 3V3, respectively.

This selects steady link function for LED1, as goes also to mentioned XMC input pin for ESC monitoring use. And 10Hz blinking activity for LED2, unseen as just goes via 2K2 to 3V3.

Further, the section says if the sensed power-up state of LED1 is high, then the output subsequently is low for the selected function, and vice-versa, likewise for LED2. So for LED1, low for link, as needed by the ESC, and lighting the yellow LED, as observed.

Best regards,

David

Re: BMI Issue in XMC1300 J-Link Lite CPU-13A-V1

$
0
0
Hi,

Which version of Segger JLink are you using?
Could you try with XMC Flasher tool?

Regards,
Jesus

There is a problem about TC275 CAN FIFO

$
0
0
canMsgObjConfig.control.messageLen = IfxMultican_DataLengthCode_8;

didn't run this code but if you set your data length to 8 you have to give it 8 bytes...

XMC 4200 CAN Bit Timing

$
0
0
Hello, guys.
I'm happy that you've solved your problem, discussed in this thread.

I have another question about XMC4200 bit timing.
How can I switch it on the fly, specially, if my hardware is already initialized by DAVE's init functions.
Namely, I need to reinit my CANs from 83333 to 500000.
Here is my code, which does not work:
Code:

void CANxUpdateBaudrate( const CAN_NODE_t* handle, uint32_t baudrate )
{
  //Disable CAN node participation in CAN traffic
  XMC_CAN_NODE_SetInitBit(handle->node_ptr);
  //Function to configure the baud rate based on UI configuration
  //Keep sample_point and sjw as they was before, update baudrate.
  CAN_NODE_ConfigBaudrate(handle, baudrate, handle->baudrate_config->sample_point, handle->baudrate_config->sjw);
  //Enable CAN node participation in CAN traffic
  XMC_CAN_NODE_ResetInitBit(handle->node_ptr);
}

This is usage example:
Code:

CANxUpdateBaudrate( &CAN1, 500000 );
NOTE: my CANs works fine at 83333, I have to update
Code:

  CAN1_BitTimeConfig.baudrate = 83333;
  CAN2_BitTimeConfig.baudrate = 83333;

in main.c before DAVE_Init(), because GUI does not allow to set CAN's baudrate less than 100k.


Now the method, which I use to check how it works:
I add 2 MOs on my CANs: CAN1, CAN2, one for receive and transmit respectively.
Then I add Rx and Tx events on needed MOs and link them to corresponding INTERRUPTs.
When I do so, and enable these INTERRUPTs, they start to occur and receive CAN frames as I expect.

This works fine with settings inited by GUI both at 83333 and 500000 bauds.
But do not work when I try to switch baudrate. At least INTERRUPTs do not occurs.


Sorry for using this thread for additional question. If it is better to start new thread let me know.

XMC4200 switch CAN baudrate at runtime

$
0
0
Hello, everyone.

I have a question about XMC4200 CAN bit timing.
Could you please guide me, how can I switch it at runtime?
Specially, if my hardware is already initialized by DAVE's init functions.
Namely, I need to reinit my CANs from 83333 to 500000.
Here is my code, which does not work:
Code:

void CANxUpdateBaudrate( const CAN_NODE_t* handle, uint32_t baudrate )
{
  //Disable CAN node participation in CAN traffic
  XMC_CAN_NODE_SetInitBit(handle->node_ptr);
  //Function to configure the baud rate based on UI configuration
  //Keep sample_point and sjw as they was before, update baudrate.
  CAN_NODE_ConfigBaudrate(handle, baudrate, handle->baudrate_config->sample_point, handle->baudrate_config->sjw);
  //Enable CAN node participation in CAN traffic
  XMC_CAN_NODE_ResetInitBit(handle->node_ptr);
}

This is usage example:
Code:

CANxUpdateBaudrate( &CAN1, 500000 );
NOTE: my CANs works fine at 83333, I have to update
Code:

  CAN1_BitTimeConfig.baudrate = 83333;
  CAN2_BitTimeConfig.baudrate = 83333;

in main.c before DAVE_Init(), because GUI does not allow to set CAN's baudrate less than 100k.
It also works fine at 500000 baud, if inited by DAVE_Init().

Now the method, which I use to check how it works:
I add 2 MOs on my CANs: CAN1, CAN2, one for receive and transmit respectively.
Then I add Rx and Tx events on needed MOs and link them to corresponding INTERRUPTs.
When I do so, and enable these INTERRUPTs, they start to occur and receive CAN frames as I expect.
I'm sending packets every 10 ms and all of them are received.


This works fine with settings inited by GUI both at 83333 and 500000 bauds.
But do not work when I try to switch baudrate. At least INTERRUPTs do not occurs.

For example, I'm starting to send infinit number of frames at 500000 baud/s, and while CAN initialized at 83333 it obviously does not receive anything. But when CAN switches to 500000 it still does not receive anything.

on-board wiggler 93c46 eeprom

$
0
0
Hi eric.
your code is working in my Wiggler.thank you very much.
Now DAS identify the my miniWiggler.The problem is that the miniwiggler try connect to the TC1724 but can't! I think my start KIT(TC1724 KIT) is correctly bias because i can connect in bootloader mode by the mimiwiggler.
there is any point for OCDS1 interface?
thank you.
miniwiggler schematic :
Attachment 2940
?????

XC 2287 Startup code and low level device drivers

$
0
0
Dear Infineon Tech Support,

Our team is going to work on a XC 2287 controller for a automotive applications. We needed startup code and low level device drivers so that we can start building our applications soon and evaluate.

Can you please send me startup code, low level device driver, OS or scheduler files.

Few example codes or any application notes on usage of XC 2287 controller would also be of great help.

We will be using Altium TASKING VX-toolset for C166 v2.2r3 Standard Edition as our development tool.

Looking for a positive reply.

Thanks and Best Regards,
Raghavendra P

BTS6133D Incorrect operation in inverse current mode?

$
0
0
Hi!

I use Smart Highside Power Switch BTS6133D to switch the backup SLA battery. BTS6133D have Inversave (Inverse current capability) feature.

In charge mode current flows from VBB to OUT (normal flow). Charge current limited to 2A.
In discharge mode current flows from OUT to VBB (Inverse load current). Discharge current not exceed 7A.

If current direction change from normal to inverse with device is on (pin IN is low), no problem. Power switch remain ON and no excess power dissipation occur.
If the reverse current occurs when the device is switched off (pin IN is high), excessive power dissipation occurs when the current flows through the internal diode. This is understandable and normal.

I have problem and question:

With the reverse current occurs when the device is switched off (pin IN is high), external logic detects this mode and immediately set BTS61333D to ON state by set pin IN to low.
Unfortunately, with this BTS6133D remain OFF state and a high power dissipation continues.
It looks like it's not normal.
From reading the datasheet, it's unclear how 6133D should function in this case.

Best Regards,
Mikhail
Viewing all 9892 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>