Code Examples Forum Discussions

PSoC5LP Sigrok Mini Logic Analyzer
(50 MSPS sampling, for short length signals of about 0.5 to 1 ms)

Introduction:
In search for a basic low-end logic analyzer, I came across this wonderful free and open source Sigrok software tool that seems to support many hardware boards by various manufacturers, and that has a lot of Protocol Decoders. The below article shows how to use it with FX2LP based hardware board:

Cypress EZ-USB FX2LP-based Logic Analyzer using Open Source Sigrok
PulseView - KBA229176

https://community.cypress.com/t5/Knowledge-Base-Articles/Cypress-EZ-USB-FX2LP-based-Logic-Analyzer-using-Open-Source/ta-p/252866

and FX3:

https://community.infineon.com/t5/Knowledge-Base-Articles/EZ-USB-FX3-Explorer-kit-as-16-channel-100-MHz-logic-analyzer-with-sigrok/ta-p/283993

Trying to use the Sigrok software with PSoC5LP, I also stumbled across a nice ready PSoC Creator project in Github by MinatsuT !!

https://github.com/MinatsuT/PSoC5_USB_LogicAnalyzer

It mentions the below limitation "Maximum capturing frequency is 250kHz. This limitation comes from the bandwidth of USB Full Speed (12Mbps)."

But for some measurement and test applications, it may be sufficient to just capture a short finite length digital signal (ie, it does not have to be continuous data streaming). For this, if the RAM memory in the chip itself is sufficient(for example there is up to 64KB RAM in PSoC5LP devices), then we can consider options to capture digital signals at relatively higher sampling rates as supported by the chip, just dumping all the captured data to the RAM during the time critical capturing duration(in the order of uS), and then let the chip leisurely send the data to a PC over USB or other communication interface at a relatively slower rate (in the order of mS or seconds).

The attached project takes advantage of the "multi-spoke DMA architecture" present in PSoC5LP device to directly move the data from the port pins to RAM buffers at the maximum possible rates supported by the chip. For example, with the bus clock running at 48 MHz, this multi-spoke DMA can be configured to move 1 byte of port data to RAM every bus clock cycle.

Applications:
For those who already have a Kitprog board such as CY8CKIT-042, or other boards with Kitprog, it may double up as a small logic analyzer. Or the project may be ported to CY8CKIT-059. It may be useful for universities, students/amateur engineers, work-from-home, or field engineers for performing basic digital signal viewing tests such as:
- Checking if a KHz/Mhz clock is oscillating at the expected frequency
- Checking if an ADC EOC(End of Conversion) signal is coming out right
- Pulse widths in the order of a few 10s of nano-seconds etc

It may also be used to create custom-triggers (using the UDB PLDs/datapaths etc) to capture a bunch of signals when an unexpected event occurs.

Some Known Issues and Limitations:

1) The first few bus clock cycles (about 4-5) following the capture event would not be captured and would be missed, as the DMA needs to "warm up", ie, a few overhead clock cycles are required between the DMA request and the actual data being transferred by DMA(due to DMA state machine phases such as arbitration etc). So for applications that are critically looking at events that happen within about the first 1 uS following the capture event, this approach of using the PSoC5LP as Logic Analyzer may not be useful. (Only after these first few bus clock cycles, the DMA will be able to transfer 1 byte of data per bus clock cycle, from the Port register to RAM.)

2) During the critical capture duration (less than 1 ms at 48 MSPS), the DMA might hog the complete 100% bus bandwidth, and CPU might not be able to operate. Other hardware blocks should be able to operate.

Hardware:

CY8CKIT-042, Jumper wires

Software:

PulseView from Sigrok:

https://sigrok.org/wiki/Downloads

PSoC Creator 4.4

Projects:

1) Main project for PSoC5LP-Kitprog on CY8CKIT-042. This will act as the mini-Logic Analyzer. This is a bootloadable project that will replace the Kitprog firmware (Programmer/Debugger/I2C Bridge etc) on the CY8CKIT-042. This has a “.cyacd” file that will be bootloader to the PSoC5LP device.
2) Optional PSoC4 based test project (that uses the PSoC4 device on the same CY8CKIT-042) to feed test input signals such as Clock, PWM, ADC EOC pulses, SPI. This has a .hex file that will be programmed to the PSoC4 device.
Note: Should be directly feasible to use the main PSoC5LP project on other boards that use same Kitprog. Other Kitprogs(such as Kitprog2) may need some modifications.

Attachments:

1) PSoC5LP project
2) PSoC4 test project
3) Test Procedure document, with driver binding screenshots (using a "Zadig" tool that comes with PulseView)
4) The direct PSoC5LP cyacd file and PSoC4 test hex file are also attached as a zip file for quick access.
5) The original 16-Channel PSoC5LP Logic Analyzer(for CY8CKIT-059) from GitHub by MinatsuT, for continuous streaming of data at about 250 KSPS. Note that a micro-USB cable needs to be connected to CY8CKIT-059.

Some other PulseView Screenshots are also attached.

Note regarding sampling frequency:

The sampling frequency is fixed at 50 MHz for now (ignoring whatever setting is made at the PulseView frequency setting).

However, if the PulseView frequency setting is set to 50 KHz, then the timing values as calculated by PulseView provides the correct frequency number of the signal. But the units are 1000x slower than the actual signal So, if a frequency is seen as "1 KHz" it has to be interpreted as "1 MHz", and if a pulse timing is seen as "5 ms", it has to be interpreted as "5 uS", and so on.

(This setting has been made because there seems to be some issue with the 48 MHz frequency setting in the PulseView, so an approximate closer value for quick readability is chosen for now, the PLL in the device is set to 50 MHz. Hence the MHz - KHz variation)

For UART, the baud rate has to be divided by 1000, and fed in the UART protocol decoder in PulseView. For example, when using 115200 baud rate, it has to be entered as just 115. And only a few bytes can be viewed because hardly 1 ms of data would be captured. So instead, for UART and slower protocols, the continuous logic analyzer firmware(with ~250 ksps sample rate) can be used. Or, if the speed needs to be somewhat faster than that, this project needs to be modified to use slower bus clock values than 50 MHz, so that few more milliseconds of captured data can be viewed.

PulseView screenshots:

Clocks ScreenshotADC EOC Pulses Screenshot

Notes on PulseView:

For timing decoder, change the ‘Edges to check” to “Rising” (by default it is at “Any”, which would show double the frequency of a clock. 
The dark theme can be selected in:
 PulseView settings - > General -> User Interface Theme “QDarkStyleSheet”

Hi,

let me share one example file to confirm the function OV and COV of iMOTION2.0.
There is a description about OV and COV in the software reference manual as below.
Please check attached files about how to check and the result. You can know detail of the functions.

Best Regards,
Kazunari Hayashi

[Overview]
This code is based on a " UART2 sample code for TLE984x" sample code which I posted it before.
https://community.infineon.com/t5/Code-Examples/UART2-sample-code-for-TLE984x/m-p/357169#M1320

ADC1 module has two mode of “Sequencer modes”and "Software mode".
I could fine out some ADC1 sample codes, but I couldn't find out Software mode sample code.
So, I just created this sample code of ADC1 Software mode as your reference.

Note:.
    UM v1.3 has V_LSB equation (17) for ADC2. However, I could not find the V_LSB equation for ADC1.
    Thus, I used the following general formula for a 10bit-ADC. Refer to line 195 of file main.c.
                     V_LSB = V_ref / (2^10 -)

[Usage]
1) Connect a TLE984x Evalboard and your PC with USB cable, then program this code via uVision.
2) Lunch a Terminal software of your PC, then connect with TLE984x Evalboard at baud=115200bps.
3) RESET & Run your board. The following will be show in your Terminal software.
     After that, please follow the Menu.
     The following shows that user enter a [7] key to show both CH7/P2.1 ADC1 value and converted voltage value.
     By the way, all P2.x-pins are pull-upped.
     And HS1-pin is Hi-output to pull-up MONx-pins of TLE984x Evalboard.

-------------------------
... ADC1 Software mode test for TLE984x ver.1 ...
*** Menu ***
Key=0: Software mode-Ch0 /VBAT
Key=1: Software mode-Ch1 /VS
Key=2: Software mode-Ch2 /MON1
Key=3: Software mode-Ch3 /MON2
Key=4: Software mode-Ch4 /MON3
Key=5: Software mode-Ch5 /MON4
Key=6: Software mode-Ch6 /MON5
Key=7: Software mode-Ch7 /P2.1
Key=8: Software mode-Ch8 /P2.2
Key=9: Software mode-Ch9 /P2.3
Key=a: Software mode-Ch10/P2.6
Key=b: Software mode-Ch11/P2.7
Key=c: Software mode-Ch12/P2.0
Input Number > 7
CH-7 = 0xc54, 4.265[V]
-------------------------

[Environment]
Confirmed evaluation boards : TLE984x Evalboard
                                                                TLE984x AppKit (Note, VBAT-pin is not connected with VS-pin)
IDE :                                                       uVision V5.36.0.0
Software :                                           UART2_TTY_EXAMPLE_TLE984x_ADC1_SWmode_v1.zip

This is an example code to show you how to tune parameters and debug for BLDC Motor.
The uC/Probe can watch signals by visualization, it is useful for realtime debug as a motor control.
This example is implemented uC/Probe into the DAVE CE project and used the oscilloscope function to debug the motor.
Please check out an attached ppt and zip.

BLDCモータのパラメータチューニングとデバッグの方法を紹介するサンプルコードです。
uC/Probeは信号を可視化して見ることができるので、モーター制御のようなリアルタイムデバッグに有効です。
DAVE CEプロジェクトへuC/Probeを実装し、オシロ機能を使用してモーターデバッグを実施しました。
詳細は添付のパワポとDAVEアーカイブ(Zip形式)を確認ください。

Best Regards,
Kazunari Hayashi

Hi 

When communicating data using the component's Slave Select (SS) on the SPI master, SS becomes inactive when the TX FIFO becomes empty.
Therefore, in many cases, I think that the SS signal is controlled by software with GPIO output.
In the case of SPI master communication for a few bytes which is not so many, it is also possible to use "Criticalsection" like this sample code.
Try it in your application. However, please conduct sufficient evaluation.

I connected FRAM as an SPI slave because I needed a communication partner, so it doesn't have to be FRAM. Therefore, 2 bytes of data are transferred, but 3 bytes of Instruction (OPcode) and address are added, so a total of 5 bytes are sent.

If SW2 is pressed, 2-byte data are written to FRAM and then read. The write buffer and read buffer are compared and the result is output to the PC terminal software using UART. The read operation is performed 5 times and the write buffer and read buffer are compared each time.
There are two types of 2-byte data, and each time SW2 is pressed, they are alternately written to FRAM.

Criticalsection specification can be removed by commenting out the #define critical_section line in “FRAM_SPI.h”.
SPI communication with FRAM doesn't work because the TX FIFO is empty halfway through.

The serial port settings of terminal software are as follows.
baud rate: 115200bps
data length: 8bit
parity: none
stop bit: 1bit

Hi,

This sample code is a I2C pseudo master for evaluation of I2C slave with error handling as below.
https://community.infineon.com/t5/Code-Examples/I2C-slave-error-handling-for-CY8CKIT-145-40XX/m-p/218789

The counterpart I2C slave is the same as the EZI2C with a 1-byte buffer. The base address following
the I2C slave address must be 0 and there is a 1 byte buffer.

Please see the attached I2C pseudomaster Function ID.pdf. Sending the Function ID in the table
with the PC terminal software outputs the waveform on the right side from the pseudo I2C master.

An example of terminal software is Infineon's SerialPortViewer. The left window is the I2C pseudo master.
When you send Function ID 0x14(dec:20), I2Cslave receives 0x12.
Similarly, if you send Function ID 0x19(dec:25) I2Cslave will occur I2CS_I2C_SSTAT_RD_ERR.

Thanks and regards,

Hello,

This sample code implements SPI master and DMA for RX (RxDmaM) and DMA for TX (TxDmaM) components on CY8CKIT-149(CY8C4147AZI-S475). Access to FRAM is performed once for a write operation of 1K bytes  data stored in the FLASH memory, and divided into eight read operations with a size of 128 bytes. When SW1 is pressed, write operation is performed, then read operation  and compare is performed.

Descriptors 0 and 1 each have a size of 16 bytes and are continuously transmitted by a chain.

Terminal software settings are shown as an example using Tera Term.

The transferred data and comparison result are below.

The data in FLASH are 2K bytes, and the first half 1K and the second half 1K are alternately sent to FRAM each time SW1 is pressed.

Best regards,

Yocchi

The heat of the Year End and the New Year hustle has calmed down.

But I've been struggling with my private project, which is a Fingerprint Scanner, namely GT-521F32.

Anyway, finally I could come up with the initial working version.

Although we've already been familiar with a Fingerprint Scanner with iPhones and Smartphones,

I wanted to play with one. And I found a reasonable priced one.

Fingerprint Scanner - TTL (GT-521F32) - SEN-14518 - SparkFun Electronics

So I gave a try, since it is connected via UART, it seems to be easy to handle.

Well, communicating with module was easy, but control the device was another story (at least to me).

The schematic looks like

According to the programming guide term, to register a finger print is "enroll".

Since finding 200 person sounds difficult, I used a few of my fingers to try.

I enrolled my left thumb as 0, left index as 1, right thumb as 2, right index as 3...

To enroll a finger, the device requires us to release and touch the finger 3 times.

Then we can identify a finger (print) if it's enrolled or verify if enrolled finger can be verified correctly.

moto

I have just posted this code for your reference.

[Overview]
This code is an example to executing RAM code in the RAM memory area.
You can reuse this project if you want to execute specific code in the RAM.
   RAM code file name = RamCode.c
   code area 　    　　 = 0x1800_0000 ~ 0x1800_0FFF
                                                Please refer to [RAM code settings] for more detail.

If your RAM code is larger than 0xFFF size, you need to adjust code size in the
"Options for file 'RamCode.c'" by right-click on the RamCode.c file.

This code can measure the execution time of both Flash and RAM with an oscilloscope
by monitoring the P0.5 pin. (fSYS=LP_CLK)

   P0.5:
        First Hi period = RAM execution time of 100 times NOP code. (about 5.7us)
        2nd Hi period = Flash execution time of 100 times NOP code. (about 11us)
   P0.4:
        Output fSYS clock (LP_CLK is selected while execution of the NOP test code.)

[Environment]
Confirmed evaluation boards :  TLE984x Evalboard
IDE :                                                       uVision V5.36.0.0
Software :                                           TLE9844_2QX_Proj_RAMcode.zip
 
[Instructions]
   1) Program this software into your evaluation board via uVision
   2) Connect oscilloscope at P0.4 and P0.5 if you want to measure the execution time.
   3) Run from uVision

[RAM code settings]
   ① Right-click on the RamCode.c file
   ② Select “Options for File ’xxx’” from the menu
   ③ Input RAM code address range. (Should be larger than actual code size)

[Execution image]

This is a demo project showing simple Sine / Ramp / Triangle wave generator using software DDS generator and double-buffered DMA. It is designed to operate on PSoC5 boards.

In this demo, the wave data (e.g. sine) is stored in FLASH as a 8-bit wavetable, and the sine data is pulled from the table at constant sampling clock. The run-time sine phase is calculated using 32-bit software DDS calculator, while only top 8 bits are used for sine phase. The data are adjusted for amplitude and stored in the temporary RAM buffer of the WaveGenLT. The Wave custom component encapsulates all DDS-related code.

Calculated data are transferred from the RAM buffer to the VDAC8 using double-buffered DMA. The buffer consists of two halves; the data from one half are fed into VDAC while another half is being populated by CPU. Such approach allows for high VDAC update rates (~1MHz), while interrupt requests for the buffer update come at much slower rate (~4kHz). The WaveGenLT custom component encapsulates all DMA-related code.

As shown, at 48MHz BUS_CLK the time to populate a half-buffer is approx. 50us, resulting in average CPU load of 20%. Highest achievable output frequency (with optional external low-pass filter) is about 100-150kHz (with 1MHz sampling clock).

Attached demo project includes all necessary components. It also allows for amplitude and frequency sweep.  All components provided as-is, no datasheets available at this time.

/odissey1

Figure 1. Project  schematic. DDS sampling clock is 512kHz, VDAC scale is 4V. The WaveGenLT total buffer length is set to 256 (128+128). Wave p-p amplitude is set to 255.

Figure 2. Project annotation for CY8CKIT-059 Prototyping Board using PSoC Annotation Library v1.0.

Figure 3. Sine wave output. Frequency - 1 kHz, amplitude p-p 4V, offset 2V.  The slight deviation of the output frequency (1.014kHz vs. preset value of 1.000kHz) is due to the inaccuracy of the IMO clock of the PSoC5.

Figure 4. FFT of the sine wave output. Frequency 1 kHz, amplitude p-p  4V, offset 2V. THD is better than 40dB.

Figure 5. Ramp wave output. Frequency 1 kHz, amplitude p-p  4V, offset 2V.  

Figure 6. VDAC sine output with amplitude modulation and persistent display. Frequency - 1 kHz  Amplitude sweep from 25 to 255, center offset 2V.