PSoC™ 6 Forum Discussions
Hi! There is a sample code on the DPS Library of Modus ToolBox. I followed the steps given and modified the code to define the SDA and SCL pins of the Board.
However, it seems to not work.
#include "cyhal.h"
#include "cybsp.h"
#include "cy_retarget_io.h"
#include "xensiv_dps3xx_mtb.h"
xensiv_dps3xx_t pressure_sensor;
cyhal_i2c_t i2c;
cyhal_i2c_cfg_t i2c_cfg = {
.is_slave = false,
.address = 0,
.frequencyhal_hz = 400000
};
#define DPS_I2C_SDA (?) // Define me
#define DPS_I2C_SCL (?) // Define me
int main(void)
{
cy_rslt_t result;
/* Initialize the device and board peripherals */
result = cybsp_init();
CY_ASSERT(result == CY_RSLT_SUCCESS);
__enable_irq();
/* Initialize retarget-io to use the debug UART port */
result = cy_retarget_io_init(CYBSP_DEBUG_UART_TX, CYBSP_DEBUG_UART_RX, CY_RETARGET_IO_BAUDRATE);
CY_ASSERT(result == CY_RSLT_SUCCESS);
/* Initialize i2c for pressure sensor */
result = cyhal_i2c_init(&i2c, DPS_I2C_SDA, DPS_I2C_SCL, NULL);
CY_ASSERT(result == CY_RSLT_SUCCESS);
result = cyhal_i2c_configure(&i2c, &i2c_cfg);
CY_ASSERT(result == CY_RSLT_SUCCESS);
/* Initialize pressure sensor */
result = xensiv_dps3xx_mtb_init_i2c(&pressure_sensor, &i2c, MTB_DPS3XX_I2C_ADDR_DEFAULT);
CY_ASSERT(result == CY_RSLT_SUCCESS);
for (;;)
{
/* Get the pressure and temperature data and print the results to the UART */
float pressure, temperature;
xensiv_dps3xx_read(&pressure_sensor, &pressure, &temperature);
printf("Pressure : %8f\r\n", pressure);
printf("Temperature: %8f\r\n\r\n", temperature);
cyhal_system_delay_ms(1000);
}
}
Is it possible to request for instructions with regards to the code and/or sample? Thank you
Regards,
Aaron
Show LessHello,
I have started a project from the PDM to I2S example ( https://github.com/Infineon/mtb-example-psoc6-pdm-to-i2s ) in which I have developed an audio bypass system (to later implement our audio processing system on it) instead of the recording-playing app.
So far I have achieved this goal at a sampling rate of 8 KHz. I need to use a sampling rate of 16 kHz. Changing the MCLK value for the audio codec and the sampling rate define to 16 kHz effectively changes the sampling rate, however, it makes appear undesired harmonics in the higher frequencies. I tried playing a sinusoid of 2400 Hz directly from the mcu to the codec and it also creates these harmonics, as in the attatched spectogram screenshot. I also attatch the screenshot at 8 kHz.
My configuration is the following:
i2s is master, codec working in EXT slave mode with 256fs (same as the example)
/* Master Clock (MCLK) Frequency for the audio codec */
//#define MCLK_FREQ_HZ 2041000 /* for 8 kHz */
#define MCLK_FREQ_HZ 4096000 /*for 16 kHz */
/* Duty cycle for the MCLK PWM */
#define MCLK_DUTY_CYCLE 50.0f /* in % */
/* Desired Sample Rate */
#define SAMPLE_RATE_HZ 16000u
/* Decimation Rate of the PDM/PCM block */
// sinc rate = decimation rate / 2
#define DECIMATION_RATE 64u
/* Clock Settings */
#define AUDIO_SYS_CLOCK_HZ 98000000u /* in Hz. Ideally 98.304 MHz */
/* HFCLK1 Clock Divider */
#define HFCLK1_CLK_DIVIDER 4u
/* ... */
const cyhal_i2s_config_t i2s_config = {
.is_tx_slave = false, /* TX is Master */
.is_rx_slave = false, /* RX not used */
.mclk_hz = 0, /* External MCLK not used */
.channel_length = 32, /* In bits */
.word_length = 16, /* In bits */
.sample_rate_hz = SAMPLE_RATE_HZ, /* In Hz */
};
const cyhal_pdm_pcm_cfg_t pdm_pcm_cfg =
{
.sample_rate = SAMPLE_RATE_HZ,
.decimation_rate = DECIMATION_RATE,
.mode = CYHAL_PDM_PCM_MODE_STEREO,
.word_length = 16, /* bits */
.left_gain = CYHAL_PDM_PCM_MAX_GAIN, /* dB */
.right_gain = CYHAL_PDM_PCM_MAX_GAIN, /* dB */
};
/* ... */
clock_init();
/* Initialize the Master Clock with a PWM */
cyhal_pwm_init(&mclk_pwm, MCLK_PIN, NULL);
cyhal_pwm_set_duty_cycle(&mclk_pwm, MCLK_DUTY_CYCLE, MCLK_FREQ_HZ);
cyhal_pwm_start(&mclk_pwm);
/* Initialize the I2S */
cyhal_i2s_init(&i2s, &i2s_pins, NULL, NC, &i2s_config, &audio_clock);
//cyhal_i2s_register_callback(&i2s, i2s_isr_handler, NULL);
cyhal_i2s_register_callback(&i2s, i2s_callback, NULL);
cyhal_i2s_enable_event(&i2s, CYHAL_I2S_ASYNC_TX_COMPLETE, CYHAL_ISR_PRIORITY_DEFAULT, true);
/* Initialize the PDM/PCM block */
cyhal_pdm_pcm_init(&pdm_pcm, PDM_DATA, PDM_CLK, &audio_clock, &pdm_pcm_cfg);
cyhal_pdm_pcm_register_callback(&pdm_pcm, &pdm_pcm_callback, &pdm_pcm);
cyhal_pdm_pcm_enable_event(&pdm_pcm, CYHAL_PDM_PCM_ASYNC_COMPLETE, CYHAL_ISR_PRIORITY_DEFAULT, true);
#ifdef USE_AK4954A
/* Initialize the I2C Master */
cyhal_i2c_init(&mi2c, CYBSP_I2C_SDA, CYBSP_I2C_SCL, NULL);
cyhal_i2c_configure(&mi2c, &mi2c_config);
/* Configure the AK494A codec and enable it */
result = mtb_ak4954a_init(&mi2c);
/* If the initialization fails, reset the device */
if (result != 0)
{
NVIC_SystemReset();
}
mtb_ak4954a_activate();
// mtb_ak4954a_set(AK4954A_REG_PWR_MGMT2, 0x08);
mtb_ak4954a_adjust_volume(AK4954A_HP_VOLUME_DEFAULT);
//mtb_ak4954a_write_byte(AK4954A_REG_MODE_CTRL2, AK4954A_MODE_CTRL2_CM_512fs | AK4954A_MODE_CTRL2_FS_32kHz);
#endif
I'm not sure but may it have anything to do with the pwm generated clock? Any help would be appreciated.
Thank you
jp
Show Less
We are using the CYBLE-416045-02 module and are experiencing problems when loading the code via the PSoC Programmer 3.29.1. The application runs fine when loaded directly with PSoC Creator 4.4 but does not when loaded with the programmer. The problem has been isolated to the IPC pipe messages not getting through to the CM4 processor.
The IPC example code in CE223820 was used to verify the problem. The example was modified to use CYBLE as the target device and was compiled and run with Creator 4.4. It worked properly.
Then, the hex file from the project was loaded with the PSoC Programmer. It produced the initial lines in Tera term but then, when "1+2" was entered it just hung.
The programmer settings are
Programmer: KitProg3 etc.
Programming Mode: Reset
Verification: on
Autodetection: on
Protocol: SWD
There must be some other settings or conditions that I am missing. Any ideas?
Show LessHello Infineon Support,
I ran into a frustrating issue today with my CY8CPROTO-062-4343W eval board. I have been developing and debugging an application on the board for a couple of weeks now. Suddenly today, I am unable to program the board with the KitProg3 debugger. When I try to launch a project (in ModusToolbox 2.4.0), I get the following output:
Open On-Chip Debugger 0.11.0+dev-4.3.0.1746 (2021-09-16-07:59)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter srst delay: 25
adapter srst pulse_width: 25
** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : Using CMSIS-flash algorithms 'CY8C6xxA_SMIF' for bank 'psoc6_smif0_cm0' (footprint 15752 bytes)
Info : CMSIS-flash: ELF path: ../flm/cypress/cat1a/CY8C6xxA_SMIF.FLM
Info : CMSIS-flash: Address range: 0x18000000-0x1FFFFFFF
Info : CMSIS-flash: Program page size: 0x00001000 bytes
Info : CMSIS-flash: Erase sector size: 0x00040000 bytes, unified
Warn : SFlash programming allowed for regions: USER, TOC, KEY
It doesn't matter if I try to program the board in debug mode or not, I always get this error. I've tried programming my project, as well as multiple different example projects. I've tried pressing the reset button on the board as well as the SW3 MODE button on the programmer, in different sequences. I have tried all the USB ports on my computer. I have tried restarting my computer. No matter what I do, I get this error.
It also seems to be something local to my computer. I have multiple eval boards, and when I try to program any of them from my PC, I get this error. However, I had my co-worker try to program them from his PC, and then they worked.
I am also not able to connect to the board in the PSoC Programmer application (version 3.29.1). When I try to connect, I always get this error: 'Can't Open CMSIS-DAP port'
Failed Connect to at 12:49:08 PM | Can't Open CMSIS-DAP port
Opening Port at 12:49:08 PM |
Could someone please let me know what could be causing this issues.
Best regards,
Cory
Show LessI just tried to upgrade from PDL v3.4 to v3.5. The dfu_user.c v3.4 uses the include:
#include "transport_ble.h"
In dfu_user.c v3.5 this changed to:
#include "transport_uart.h"
My build now blows up because it cannot find the file transport_uart.h. My system does DFUs over bluetooth and this sounds like it wants to use a UART for the BLE. Anybody know what is going on here and how I should go about fixing it? Do I just edit the new dfu_user.c back to using transport_ble.h?
Thanks,
Ed H.
Show LessHi ,
I have one question Is there any method to check if the device is returned from Backup Domain. I am working on device in which Backup domain is required for time tracking and other implementations.
I have looked into Technical Reference Manual Section for Backup Systems and Power Supply where I found VDDBAK_CTL for switching the Power rail between VDDD and VDDBAK.
I also looked into Registers Technical Reference Manual for Backup System Registers BACKUP_STATUS But it only tells the status of WCO and RTC_Busy not if system is returned from BACKUP domain
I also tried to look into Pdl reference manual no API found that could help me.
Kindly help me with the situation
Show Lessi am trying to carry out clock glitching with the new target board PSoC 62 with Chip Whisperer pro kit. but am not able to. after making changes in the code there is not effective changes seen, the results are the same.
attached is the file with changes made please help me out what am i missing are doing wrong?
Show LessWe are using the CYBLE-416045-02 module in a doppler radar speed collection
module that sends traffic speed data to a server. We have a half dozen
units in the field for testing and the system is running very well.
An external FRAM is being used for parameter and system state saving during
processor hibernation. For system reliability we want to also save the
parameters in PSoC 6 flash using the EEPROM V2.20 component. Creator 4.4
is being used for development.
The "Em_EEPROM" component was first configured with 1024 bytes, redundant copy,
blocking write and no wear leveling. Auxiliary audits were added to see the
results of the writes and reads on the EEPROM. At first nothing went through;
even the initialization returned a CY_EM_EEPROM_WRITE_FAIL. After
various trials with the configuration, a number of writes and reads
went through with no redundant copy and non-blocking writes. After more
experimenting, I could not even get that case to work any more.
Also, when the EEPROM component is active none of the ipc functions which are
used to communicate between CM0p and CM4 were working any more.
So, the EEPROM component must be interfering with the ipc operation.
To check this further, a compiler conditional variable was added to
be able to comment out the new EEPROM interface code. When
the EEPROM was allowed to be compiled in, the system did not
work. When it was not, the system worked as well as before starting
to add the EEPROM.
So, the problem is what should I be doing to prevent this interference.
The documentation for EEPROM does not say anything about such
interaction and I do not know what internal chip resources the
EEPROM is using that might be colliding with those used by ipc.
This should not have to be known to the user.
Also, the documentation for the EEPROM component is much too sparse.
For example, writes can be in non-blocking mode. Normally when
this is provided, there is a way of starting the operation and a
way of checking when the operation is done. There is no information
about this in the EEPROM documentation.
A second example is the return codes. Sure, they are defined. But,
what the user needs to know is why did a write error appear and
what should be done to fix it.
The only EEPROM calls used in the interface are the following:
fnvm__status= Em_EEPROM_Init(0); // address not used in PSoC 6
fnvm__status= Em_EEPROM_Write((U4)ind,(V *)vUP,(U4)nb_used);
fnvm__status= Em_EEPROM_Read((U4)ind,(V *)dUP,(U4)nb_used);
The following are the ipc calls used in the CM0p and CM4 processors:
CM0p:
CY_IPC_EP_CYPIPE_ADDR
, ipcCB_cm0p_rx_msg
, CY_IPC_EP_CYPIPE_CM4_ADDR
);
Cy_IPC_Pipe_SendMessage(
CY_IPC_EP_CYPIPE_CM4_ADDR
, CY_IPC_EP_CYPIPE_CM0_ADDR
, (void *) &ipc0__ipc_msg
, ipcCB_cm0p_tx_release
);
CM4:
CY_IPC_EP_CYPIPE_ADDR
, ipcCB_cm4_rx_msg
, IPC_CM0_TO_CM4_CLIENT_ID
);
Cy_IPC_Pipe_SendMessage(
CY_IPC_EP_CYPIPE_CM0_ADDR
, CY_IPC_EP_CYPIPE_CM4_ADDR
, (void *) &ipc4__ipc_msgT
, ipcCB_tx_release
);