PSoC™ 4 Forum Discussions

There are many inconveniences because the number of collected data that can be stored in BCP is limited to 10,000.

If you look at the attached image file, you can see the outliers in the actual data on a graph, but it cannot be saved and analyzed.

Regarding some inquiries, it is said that the problem has already been forwarded to the SW team.
Why isn't an improved version released?
Why is data stored only after it is collected? You can just save the data as a file right away...

We ask for a quick resolution.

这是官网给的资料显示

这是当前版本显示， 大部分地方都对应不上，导致编译出错无法跟踪问题，请问哪有最新资料或者补丁？

I am querying the register address and value of chip id of products CY8C4046FNI-T412T and CY8C4046FNI-T452EST,  I do not know whether I have searched correctly.
The register address for chip id we found in the 400T series specification is 0x0FFFF144. Is the chip id address of the 400T series the same?
The corresponding register values are shown in the following two pictures.
I hope someone can help with that. Thank you very much.

The datasheet says Bluetooth 5.1 Qualified,  but PSoc Creator 4.4 BLE Component v3.66 is only Bluetooth 4.2.  Is this device capable of any of the BLE 5.1 features like connectionless broadcast or extended advertising?

Dear Sir,

We saw the PSoC4700 inductive could support up to 16-channel inductive sensing.
I tried to use the PSoC creator to build up the solution but the MagSense Lx is limited to assign on Port 2 8pins only.
How to make a 16pins inductive solution?

Best Regards,
Billy

I want to do the following:

1. Send a 6 byte command to an SD card over SPI, interrupt on TX Empty (when command is fully moved out of the FIFO)

2. In ISR, empty the receive FIFO with either SCB_SpiUartClearRxBuffer() or reading the bytes.

3. Send dummy byte 0xFF, interrupt on TX empty, read RX byte, until a non-0xFF value is received (response from SD card).

So, assuming the SD Card responds on the second dummy byte after the command, I should see a total of 3 dummy bytes transmitted after the command.  But, I am instead seeing 8, both in code and on a logic analyzer trace:

Using the debugger I have narrowed down the problem to this part in the ISR:

Bus trace when that breakpoint is hit (SCB is automatically de-asserting CS due to debugger pause):

Step 2 above is lines 51-54, Step 3 is the rest.  Even though I have read all bytes out of the RX buffer, or used ClearRxBuffer(), after transmitting another byte, the RX buffer size reads 5, even though it was previously 0 to break out of the do/while loop!

Why?  If I read all the RX bytes out of the FIFO/buffer, then transmit one more byte, why are there 5 bytes still sitting in the receive buffer?  Those 5 plus the 3 dummy bytes = 8 extra bytes transmitted before the response byte is read from the FIFO.

I think the issue may be due to the TX Empty interrupt firing directly after I write a 0xFF to the TX buffer, since empty triggers when the last FIFO element is moved from the FIFO to the shifter.  For example maybe the empty interrupt is firing more than once?  Is there a better way to do a single byte transmit/check response, without the SCB automatically de-asserting CS (i.e. without SPI_DONE interrupt)?

I have attached the project, it targets the CY8CKIT046 with an SD module connected to the SCB through the PMOD header (port 6).