Hi I am new to XMC microcontrollers. I have a problem in converting the analog signals using ADC app in XMC µc using DAVE IDE. I was able to convert for 1 input. But for multiple inputs it gives me wrong answer.

This is my program:

#include "DAVE.h" //Declarations from DAVE Code Generation (includes SFR declaration)

XMC_VADC_RESULT_SIZE_t result[2];
uint8_t cnt=0;

void Adc_Measurement_Handler()
{
result[cnt] = ADC_MEASUREMENT_GetResult(&ADC_MEASUREMENT_0);
cnt = cnt+1;
if(cnt == 2)
{
cnt = 0;
}

}


int main(void)
{
DAVE_Init(); //(DAVE_STATUS_t)DIGITAL_IO_Init(&DIGITAL_IO_0) is called within DAVE_Init()

ADC_MEASUREMENT_StartConversion(&ADC_MEASUREMENT_0);

return (1);
}

when i read multiple signals, my output tends to get collapsed like the output for channel 1 is stored in result[1] instead of result[0] and likewise for the rest too. Kindly help me. I don't where my problem is Show Less

Hi everyone

I'm using the CCU8 symmetric, with 50% of PWM and dead time of 400ns, for the High side, and for the Low side the same thing.

But when I want to stop PWM, I use PWM_CCU8_Stop(&PWM_CCU8_0), always one of the pins remains at a high level, and for the Half Bridge, which I'm using, this is a big problem, I need the GPIOs to be at level 0, after command PWM_CCU8_Stop(&PWM_CCU8_0) .

I already tried to force the GPIO to level 0 using LLD with the commands
XMC_GPIO_SetOutputLow(XMC_GPIO_PORT0,0);
XMC_GPIO_SetOutputLow(XMC_GPIO_PORT0,1);
But I was not successful. I did other methods and I couldn't.

Can you help me with this?

Best regards

Show Less

 

I have been trying for days to be able to receive information through the UART but when debugging I cannot observe any value that it sent through the communication port with the "Docklight" I can observe what it sent. HELP! I feel that no one responds to me in this "community" and there are not many resources and the ones that exist do not work.

Show Less

I just upgraded the version of Wiced we are using from 6.4 to 6.6.1.1. When the code tries to set wwd_wifi_fast_bss_transition_over_distribution_system the result is now WWD_WLAN_UNSUPPORTED.

The chip is a CY43012C0.

Any ideas why this no longer works?

Show Less

@Kumarkanahai@AliAsgar

Please also help to confirm whether it is normal for the power supply voltage to be forcibly pulled down, and what is the reason for the flicker?

At 9V, the PWM driver will see the LED flicker that can be recognized by human eyes. When testing the waveform with the oscilloscope, it is found that the power supply voltage is forcibly pulled down by a few tenths of a volt. When the voltage is adjusted to 10V or above, the flicker disappears, but the phenomenon of forcibly pulling down the power supply detected by the oscilloscope still exists.

This phenomenon is especially obvious when multiple devices supply power at the same time. The waveform of tail point is as follows. Please help analyze whether this phenomenon is normal and what causes it.

 

 

 

 

The following attempts and changes have been made

1. The current limit of power supply is adjusted from 5A to 10A without improvement;

2. Cancel D2 (equivalent to removing the diode 0.7V voltage drop), 9V will not flicker with the naked eye, but the waveform still exists. The capacitance of vs pin is connected in parallel with a 1uF capacitor on the basis of 0.1uF, the phenomenon is not improved, and the power supply voltage is also pulled down;

3. Test the voltage drop of LED. The voltage drop of each LED is 2.2V, and the total voltage drop of LED is about 6.6v

It is equivalent to that after D2 is removed and replaced with 0 Ω resistor, the power supply voltage will still be forcibly pulled down, as shown in the following waveform.Please also help to confirm whether it is normal for the power supply voltage to be forcibly pulled down, and what is the reason for the flicker?

 

 

Show Less

Hello Infineon,

Pin 24, VCCD which is the output of an internal 1.8V regulator for internal logic, comes up to about .9V and slowly drains down to 0. Thus, the chip has no voltage to communicate with the USB C adapter.

Electrically, it looks like my layout and their Eval Kit (CY4533 EZ-PD) are the same.

 

Please see attachments.

Thanks,

Dan

 

 

Show Less

Hi.

I'm trying to use the HAL System Power Management library to put the CM4 to sleep. So far, I've had no luck, and as I have found too many times, there is very little documentation available, and no examples. What documentation exists (e.g. Architecture TRM) is unclear, even suggesting that only masked interrupts can wake up a sleeping CPU.

Here's the environment:

• PSoC 63 with BLE in a custom board.
  • MTB 2.3.0 
  • BSP 2.3.0
  • PDL 2.3.0
  • HAL 2.1.0
• CM4 and CM0+ running FreeRTOS
• Several peripherals in use (BLE, I2C, UART, SPI, RTC, TWPCM, etc.)

1. I registered four callbacks using cyhal_syspm_register_callback(). 
2. I call cyhal_syspm_sleep().
3. The four callbacks are called with state set to CYHAL_SYSPM_CB_CPU_SLEEP and mode set to CYHAL_SYSPM_CHECK_READY. All callbacks return true.
4. The four callbacks are called again with state set to CYHAL_SYSPM_CB_CPU_SLEEP, but this time mode set to CYHAL_SYSPM_BEFORE_TRANSITION.
5. The four callbacks are immediately called a third time with state set to CYHAL_SYSPM_CB_CPU_SLEEP, but this time mode set to CYHAL_SYSPM_AFTER_TRANSITION.

The first problem is that the CPU either doesn't sleep, or wakes up immediately. I disable the RTOS SysTick interrupt in one of the callbacks. I also disable several other peripheral interrupts, and turn off the BLE stack, none of which has made a difference. It's likely that some interrupt is firing, but I can't think of a good way to determine which is the culprit.

The second problem is that the stated behavior, namely that the callbacks are called on wakeup (CYHAL_SYSPM_AFTER_TRANSITION) in the reverse of the order in which they are called on sleep (CYHAL_SYSPM_CB_CPU_SLEEP) does not match the observed behavior.
Callbacks are always called in the same order, even when one of the callbacks returns false in response to CYHAL_SYSPM_CHECK_READY.

Has anyone successfully used cyhal_syspm_sleep() to put one of the CPUs to sleep?

Thanks,

-Nick

Show Less

Hello all, 

Most of the data I'm trying to transmit seems to be going between the FX3 and the other chip just fine, but I'm periodically getting zero length packets seemingly coming from nowhere. I've been trying to debug this, but everything I've tried has been a dead end so far.

I'm trying to use the FX3 to connect an 8051 on our board with a host application on a windows PC. My setup is as follows:

• An 8051 that has the microcontroller business logic. 
  • It receives input from the host from GPIF-II addresses 1 (buffered) and 2 (immediate), sends responses on 3, and there's logging macros that use address 4.
  • It's mostly legacy code, except what I've changed to make it work with the FX3.
• The FX3 that's mainly passing data between the host and the 8051
  • I'm using the GPIF-II interface. The state machine I'm using is basically the async slave fifo interface provided as a sample, except that I've changed some of the pin numbers.
  • USB addresses 2, 4, 6, and 8 are connected to GPIF-II addresses 1, 2, 3, and 4 respectively.
  • I have an additional USB endpoint 10 that I'm using for debugging. Every time data a packet is added to one of the other buffers, I sent the contents and a little metadata to the host. This way, I can debug problems between the FX3 and the 8051 independent of the production app running on the host.
• On the Windows Host PC, I have the production app that's trying to use endpoints 2, 4, 6, and 8 to talk to the 8051. There's some other issues there that I still need to investigate, but it's at least able to consume data from the buffer so they never get too full.
• Also on the windows PC, there's a logger app that connects to endpoint 10, and formats and prints the packets that the FX3 has received from the 8051.

Now the problem I'm seeing is that, the 8051 sends a keepalive signal periodically to the host app, and every once in a while, we get a zero length packet as well.

Here's what I've tried in my investigation:

• I've set breakpoints in the 8051 code to check if the actual data we tell it to send really is zero, and it never gets triggered, so I can be sure that we don't ever try to send a ZLP. I've verified that the pins I'm using to communicate with the 8051 are only touched in the 4 read and write functions that I expect them to, so the breakpoints I mentioned should cover every situation.
• I've verified that the order in which the pins change to control the state machine is correct. That is to say to write to the buffer:
  1. SLWR = 0
  2. Write Data
  3. if this is not the last byte, SLWR=1 and go back to 1.
  4. If this is the last byte:
  5. PKTEND = 0
  6. SLWR = 1
  7. PKTEND = 1
• My coworker who designed the board suggested that timing issues could mean the state machine is in a different state than I thought it was, so I've done the following to check timing:
  • In the FX3 manual, it says the GPIF-II "Enables interface frequencies up to 100 MHz", which I assume means that it can change state at least once every 10ns. In the state machine, changing a single pin causes at most 3 state changes before it reaches a stable state, so I tried adding a 30ns delay after every time we change a pin. Then when that didn't make a difference, I added another 30ns just in case, but still no dice.
  • Then I tried adding a full 1ms delay for good measure after every time I changed a pin, which changed nothing either. I figured this would cover my bases if I was mistaken about how fast the state machine transitions.

I suspected that maybe there's noise or something changing the PKTEND pin long enough to trick the state machine into sending a ZLP, but my coworker has already dismissed that notion. He's the hardware guy, so I can't really make him check it, and he didn't leave a way to attach a scope or anything to the pin, so wouldn't be easy.

If anyone has any suggestions of what might be going wrong, or ideas for other things I could test, I'd love to hear them.

Show Less

Hello Community

We are pondering  using the IM67D120A microphone in a project. This microphone can operate in one of four modes depending on the speed of the PDM clock, see the image attached.

However the MCU we are using only allows us to chose between three different frequencies: 1, 2 and 4 MHz. As you see, this would either put us above the allowed max frequency or between LPM & mode 3 or mode 3 & mode 2.

Our preference is to run the PDM clock at 2 MHz, but what behaviour can we expect from the mic when running at an intermediary clock speed? will the microphone glitch back and forth between two modes (and cause audible artifacts) or is the mode switching more seamless and nothing bad can be expected?

 

Best regards

J

Show Less