Hi,

Could you please help me with Schematic and firmware design support to drive Segment LEDs using the PSoC 5LP chip?
We have to drive a seven-digit seven segment display with various segment current from 16-bit serial input.

Regards,

Mari 

We want to control the output of the GPIO by changing the registers.
Is it possible to know the address of the register?

This is because we are using a dynamic test tool.

Thanking in advance.

Otsuki

Hi

I am trying to use IPC to share 2 variables between M4 and M0. I am able to share a single variable, now I need to share 2, one of them is an array (buffer for UART).

I can't find app-notes for this task. Do you have any advice ?

thanks

Hello Infineon Experts,

We use a CX3 and one or two related image sensors on our board, and we are facing a CY_U3P_ERROR_FAILURE value returned by the CyU3PMipicsiSetSensorControl() API. This behavior is random, but the error rate is over 20 %.

We probed the I2C bus and some other significant signals (CX3_RESET*, CX3_XRESET and CX3_XSHUTDOWN), to look what’s happen (see attached pictures):

• On successful execution, a first reading of Register 0x0012 (CY_U3P_MIPICSI_REG_GPIOIN) is done, bits [2:1] of this value are set to ‘1’ to drive High XRESET and XSHUTDOWN pins, the changed value is written to Register 0x0014 (CX3_CSI_SENSOR_SIG_VAL) and a second reading of Register 0x0012 is performed to be sure that Register 0x0014 is correctly written. So, reserved bits of Register 0x0014 are preserved as requested to section 1.10.7 of CX3 TRM.
• On fail execution, the second reading of register 0x0012 doesn’t match the writing to Register 0x0014 and the CyU3PMipicsiSetSensorControl() API returns CY_U3P_ERROR_FAILURE. The difference concerns the reserved bit 0.

Do you have an explanation for this error CY_U3P_ERROR_FAILURE?

For your information, both SDA and SCL signals are pulled high with 2kΩ resistors, and the I2C block is initialized (by calling CyU3PMipicsiInitializeI2c() API) before initializing the MIPI-CSI-2 block (i.e. before calling CyU3PMipicsiInit() API).

Best Regards,

Eric.

I want to use several 8Mbit x8 SPI 40MHz Excelon LP F-RAM devices in an application where I need to convert signals coming from a parallel x8 SRAM interface to 40MHz SPI signals and also 40MHz SPI signals sourced from the SPI F-RAM device to signals destined for the x8 parallel SRAM interface. As for the x8 parallel SRAM interface timings, conservatively, I have a memory address setup time of around 250ns, a memory address hold time of around 1250ns and a chip enable hold time of around 750ns ( I'm not quite sure of the timings right now and I know I am missing some timing information for some of the x8 parallel SRAM signals ). I plan on doing this with an ultra-low-power MCU, but, I'd need to use cycle-stretching on the Cypress F-RAM device(s). Is the above kind of conversion doable, especially the cycle stretching?

( N.B. The devices I want to use are one of these : https://www.cypress.com/file/444186/download , https://www.cypress.com/file/444186/download )

Thanks,

jdb2

I walked into a PSOC 5LP design where it was assumed the SAR was running a full 12-bit unsigned resolution in single ended mode. This didn't appear to be the case and after struggling with settings both high level as well as low level register settings I can't seem to make it work as a 12-bit single-ended unsigned ADC. Is this possible with this device? If so, please tell me how to use it that way. Also, please add this question to the list of FAQs for these devices.

Hello, 

I am designing a capacitive sensing trackpad using the CYBLE-214015-01 module. I notice that when I have my finger also touching the battery, the trackpad works great to control the cursor of my computer use the BLE HID Mouse Trackpad code provided by Cypress. Conversely, when I am not physically touching the battery, the trackpad works poorly. Do you have any insights on why this is the case? I have added a hatched ground plane to the front and back layer of the PCB as well as solid ground planes to the two middle layers of the  PCB. Originally, I thought it was a grounding issue, however, I have maximized the amount of ground planes I can add to my design. I also added the 560 ohm resistors to each of the CapSense pins.

Thank you.

good afternoon

any ideas on why callback registered (successfully) with cy_wcm_register_event_callback() is never called when wifi disconnect from AP ?

i would be glad to get your experience on such issues.

many thanks

best regards

Hello,

I receive over SPP a batches of bytes larger than 256 (varying between 81 bytes and 800 bytes per batch with max 1000 bytes per second). By HCI tracing I was able to see that the byte batches received completely.

This batch should be send to an external MCU by use of PUART (without HW handshake). The PUART is set up properly and tested okay on 115k and 38400 baud. 

I am using in the callback function from SPP  spp_rx_data_callback the buffer-pointer p_data and the buffer length data_len to send the by wiced_hal_puart_synchronous_write(p_data, data_len)  it appears that large batches  are not  transferred correctly, say for batches larger than 256 bytes the maximum number of bytes transferred is around 256.

For batches smaller than 256 bytes (say 242) I get the correct 242 bytes plus some additional from the begin of the buffer plus some that are not assignable. 

Is there a limit of 256 bytes in the TX buffer ? 

Or is there a limit in the SPP reception buffer ?

How can I send securely these number of bytes?

    WICED_BT_TRACE("###############################\n");

    WICED_BT_TRACE("%s handle: %d len: %d %02x-%02x\n", __FUNCTION__, session_handle, data_len, p_data[0], p_data[data_len - 1]);

    WICED_BT_TRACE("###############################\n");

     wiced_hal_puart_print("\n########## BEGIN #############\n");

    wiced_hal_puart_synchronous_write(p_data, data_len);

    if (data_len>0)

    {

    wiced_hal_puart_synchronous_write(p_data, data_len);

    }

 wiced_hal_puart_print("\n##########  END  #############\n");

I am trying to compile a C/C++ makefile project using the Eclipse IDE for ModusToolbox (Version:  2.2.0, Build ID: 2181) for CY8CKIT-062-BLE  target.  I am able to compile  *.c and *.cpp files but *.cc files  is excluded from the compilation.

If I add following in the Makefile:

SOURCES = $(wildcard extlib/*.cc) 

The build console displays following error message:

../mtb_shared/core-make/latest-v1.X/make/core/build.mk:386: *** Incompatible source file type encountered while constructing explicit rule: extlib/utils.cc. Stop.