ModusToolbox users may run into errors like “OpenSSL SSL_read: Software caused connection abort, errno 113” while running github.com-related git_clone/git_fetch in ModusToolbox. It means your connection to github.com is blocked for some reason.
ModusToolbox的用户在执行与github.com相关的git_clone/git_fetch等操作时，可能会遇到错误：“OpenSSL SSL_read: Software caused connection abort, errno 113”。这通常是因为你到github.com的连接被神秘力量屏蔽了的缘故。

In this case, you can turn to use some third-party repo_relaying servers, like ghproxy.com, to bypass the restrictions. Basically, you need to run the following GIT_config command to make it work in ModusToolbox:
这时你可以使用一些第三方的repo中继服务器（譬如mirror.ghproxy.com），来绕过这个限制。基本上，你需要运行如下这个GIT_config命令来使得这个中继服务器被ModusToolbox接受：

git config --system url."https://mirror.ghproxy.com/https://github.com".insteadOf https://github.com

The tool is designed to help you with that. It automatically locates your ModusToolbox and adds the value, and then handles the conflicting settings.
这个工具被设计用来帮助你完成这个工作。它会自动定位你的ModusToolbox并添加这个设置，然后处理与之相冲突的一些设定。

Click to download the tool [source]    (or directly use this link)  

Click to download the tool [mirror]    (password: mtbs)

Latest version / 最新版本：v0.1.6.0

Guide

1. Download the latest release and unzip it wherever.
   下载最新的版本，然后随便找一个位置解压它。
2. Run the file Install.cmd.
   运行Install.cmd这个文件。
3. Reboot ModusToolbox and done.
   重启ModusToolbox，就可以了。
4. Run the file Uninstall.cmd to remove the settings. You may uninstall the tool before you update it as well.
   运行Uninstall.cmd这个文件可以移除本工具造成的更改。更新本工具之前也最好先卸载。
5. Try clear the cache of ModusToolbox first every time you encounter an error. A lot of git error stay once they occurred. Follow this link to do this.
   如果你遇到错误，请先清理缓存再进行下一步操作，每一次都是。因为很多git的错误如果发生了，那它们将一直残留，除非你清理过缓存。依照这个链接的提示来清理缓存。

Notes

1. ghproxy.com is a third-party service that can be unstable.
   ghproxy.com是一个第三方的服务，它可能不够稳定。
2. ghproxy.com is adopted in the tool but not part of the tool. Visit ghproxy.com for more info and support.
   ghproxy.com在本工具中被使用，但它不是本工具的一部分。访问 ghproxy.com 来获取更多信息，并支持它。
3. Support ModusToolbox 2.x and hopefully later.
   兼容ModusToolbox 2.x和后续的版本（可能）。
4. The tool only helps you restore accessibility to the GitHub content of ModusToolbox. If you need to use any other content of ModusToolbox (when the variable CyRemoteManifestsOverride is touched by you), you have to uninstall it first or you might see more issues coming.
   本工具只帮助你恢复对在GitHub上的ModusToolbox内容的访问。如果你需要使用在其他位置的ModusToolbox内容（此时你通常会修改CyRemoteManifestsOverride变量），你应先卸载本工具，不然你可能会遇到更多的问题。
5. The tool is provided AS IS. There is NO WARRANTY.
   这个工具是照原样提供的。它不提供任何保证。
6. Windows might prevent the scripts from executing. You might see some red warnings about the limit during the execution. Visit this link for lifting the limit.
   Windows可能会阻止本工具运行。运行本工具时你可能会看到一些关于此限制的红色警告信息。访问这里了解如何移除这个限制。

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

The tool above is for Windows only. When using Linux/macOS, it's better you add the configuration yourself:
上述工具只能在WIndows下使用。如果你使用的是Linux/macOS，更推荐你自行添加这些配置：

Open a terminal in Linux/macOS.
在Linux/macOS中打开一个命令行窗口。

Run the following command to add the git config in the terminal.
在该命令行窗口中运行下方命令添加这个git配置。

git config --global url."https://mirror.ghproxy.com/https://github.com".insteadOf https://github.com

Then add the environment variable CyRemoteManifestOverride to the system. For ModusToolbox 2.2 and later, set it to the following value:
然后添加环境变量CyRemoteManifestOverride到系统中。对于ModusToolbox 2.2或之后的版本，把该变量设成下方的值：

https://gitee.com/dreamscaperia/mtb-super-manifest/raw/master/mtb-super-manifest-fv2.xml

For ModusToolbox 2.1 and earlier, set it to the following value:
对于ModusToolbox 2.1或之前的版本，把该变量设成下方的值：

https://gitee.com/dreamscaperia/mtb-super-manifest/raw/master/mtb-super-manifest.xml

You can refer to KBA230953 for how to do it in Linux/macOS. And you may refer to this article for how to set it permanently in Linux.
你可以参考KBA230953来了解如何在Linux/macOS中设置环境变量。你还可以参考这个文章来了解如何在Linux中永久设置这个环境变量。

TC3XX ETH characteristics:

1. Supports 10/100/1000M Ethernet;

2. Supports MII/RMII/RGMII interfaces;

3. Supports full/half duplex working mode;

4. The maximum length of an Ethernet frame is 1522bytes;

Only TX DMA0 and RX DMA0 are used in 5.mCal.

The hardware structure diagram of ETH is shown in the following figure.

Key API interfaces in MCAL:

1. eth_17_gethMac_init, used to enable and reset the ETH module and initialize the Mido interface;

2. eth_17_gethMac_provideTxBuffer, used to create the specified buffer to be sent. The input parameters include Controller, BufferId, Buffer content, and length.

3. eth_17_getHMac_setControllerMode, sets the mode of the Ethernet controller.

4. eth_17_gethMac_getControllerMode to get the mode of the Ethernet controller.

5. eth_17_gethMac_setPhysAddr, set the MAC address of the controller.

6. eth_17_gethMac_getPhysAddr to obtain the MAC address of the controller.

7. eth_17_gethMac_writeMii, set the contents of the PHY register.

8. eth_17_getHmac_readMii, reads the contents of the PHY register.

9. eth_17_getHMac_transmit, Ethernet data transmission.

10. eth_17_getHMac_receive, Ethernet data reception.

11. eth_17_gethMac_Tx, callback function for Ethernet data transmission.

MCA configuration:

The first step is to configure the clock reference, as shown in the following figure.

The second step is to configure the controller, including speed, operating mode, MCA address, buffer level, MDIO, etc., as shown in the following figure.

The third step is to configure the transmission and interface interfaces, enable RGMII read and write operations, and configure the form of data reception.

The fourth step is to configure the port hardware as the reset type. All input pins used for the ETH drive must be configured as port_pin_rgmii_driver, PORT_RGMII_INPUT, as shown in the following figure.

The fifth step is to enable the transmission and reception of DMA to be interrupted.

Step 6. Compile the configured generated.h and.c files into HighTec or TASKING.

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/%E4%BE%8B%E7%A8%8B/Aurix-TC3xx-ETH-Demo/td-p/647552

1. Introduction to Trace features

The trace function is used to track and record the running status of CPU internal programs, implement code coverage statistics, CPU load analysis, historical code backtracking, OS scheduling analysis, and other functions. The implementation mode is divided into Off-Chip Trace and On-Chip Trace, Off-Chip Trace refers to the use of external trace tools to connect the target controller to achieve the Trace function, On-Chip Trace refers to the realization of the Trace function through the MCU itself, the advantage of this method is that the Trace function can be realized without external trace equipment, which is convenient for debugging and saves costs. So do all chips support On-Chip Trace? Apparently not. The implementation of On-Chip Trace depends on the Emulation device (ED) function of the chip itself, and we will take AURIX™ TC39x ED as an example to briefly introduce its functions and how to use them.

2. Introduction to AURIX™ TC39x ED

AURIX™ TC39x Emulation Devices offers the same feature set as the TC39x Standard Series, with additional debugging and tracing capabilities. The TC39xXE supports calibration, rapid prototyping, and debugging/simulation. It has 4 MB of extended memory (EMEM), of which 2MB can be used for calibration and tracing, supports Multi-Core Debug Solution (MCDS) multi-core debugging schemes, supports Aurora Gigabit Trace (AGBT), and the CPU has full access to all simulation resources, enabling all types of interfaces such as Ethernet to be connected as tools.

For descriptions of the rest of the AURIX Emulation Devices series, please refer to the following link on Infineon's official website:

AURIX™ TC2xx Emulation Devices - Infineon Technologies

AURIX™ TC37x Emulation devices - Infineon Technologies

3. On-Chip Trace live demonstration

The following demonstrates the On-Chip Trace function based on the chip of the TC39x ED model, the debugger uses the current mainstream Aurix debugger Lauterbach, and the operating system running on the 397 uses the automotive-grade CP AUTOSAR OS. Finally, Task scheduling analysis and CPU load analysis are implemented.

1) Trace function menu introduction

The menu options related to the Trace function are located in the middle section of Lauterbach's main menu. The options and meanings of each drop-down box are shown in the following figure:

2) Trace function configuration

The window after opening the Trace Configuration is shown below. If you use the OnChip Trace function, you need to select ONCHIP METHOD as Onchip.

State is used to set/display the status of Trace. OFF is to stop tracking, ARM to start tracking, and Disable is disabled. If Disable is selected, the Trace function cannot be automatically turned on or configured.

SZIE is used to set/display the storage size (in the case of EMEM, the maximum space is 2MB), and Mode is used to set/display the storage mode for Trace data.

3) Trace MCDS settings

MCDS is used to set which CPU's data is tracked, and which data to track. The timestamp activation is also set on this page.

4) ORTI file import

ORTI is generated by the AutoSAR OS configuration tool. In this article, we use Vector's davinci configurator to generate it. Importing this file into Lauterbach software can be used to analyze the symbol table corresponding to the OS. After importing Trace, there will be a few more functional options related to OS Tasks, as shown in the following figure. If you use the command line method to import, you can use the following command: TASK.ORTI D:\ORTI_Path\Os_Trace.ORT

5) Task Switches breakpoint settings

Set the breakpoint when the task is switched, and set the action when the breakpoint occurs to traceEnable, then you can use the Trace function to record each task switch.

6) Trace data entry

By clicking Arm to start recording Trace data, the blue progress in used shows the actual storage space occupied by Trace data. If you need to stop recording, click OFF.

7) View CPU load and task scheduling

After the Trace data acquisition is completed, you can view the CPU load and scheduling status through the Perf option Task Runtime, and analyze OS performance and troubleshoot related issues based on this

😎 Use of Lauterbach CMM scripts

The following script can be used to automate the configuration of the above operations

Print " Initiatives ORTI Support... "
TASK.ORTI D:\ORTI_Path\Os_Trace.ORT
System.memaccess.CPU; allow to access to other memory while running
system.cpaccess.enable; allow to access CPU memory while running
Targetsystem
PRINT " LOAD COMPLETE. "
PRINT TASK.CONFIG (magic)
mcds.source.set cpumux0.core TriCore0
mcds.source.set cpumux1.core TriCore2
Break.Set TASK.CONFIG (magic [0]) /Write /traceEnable
Break.Set TASK.CONFIG (magic [2]) /Write /traceEnable
mcds.timestamp ON
CLOCK.ON
MCDS.source.set cpumux0.program OFF
mcds.source.set cpumux1.program OFF
mcds.source.set cpumux0.writeaddr ON
mcds.source.set cpumux0.writedata ON
mcds.source.set cpumux1.writeaddr ON
mcds.source.set cpumux1.writeData ON
ENDDO

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/%E4%BE%8B%E7%A8%8B/%E5%9F%BA%E4%BA%8EAURIX-Emulation-device-ED-%E5%8A%9F%E8%83%BD%E5%AE%9E%E7%8E%B0On-Chip-Trace-%E5%AF%B9OS-%E8%BF%9B%E8%A1%8C%E5%88%86%E6%9E%90/td-p/642764

Based on the device acceleration (acceleration sensor value) how to wake up the device? In example code where we can set the Acceleration sensor threshold value for wakeup.

We will post sample code for XMC2Go, the smallest evaluation kit in the XMC microcontroller series.

Features of XMC2Go

• Equipped with XMC1000 microcontroller
• On-board debugging capability, no need for ICE or other debuggers
• 3.3V operation with USB power supply
• Equipped with 2 LED lights
• 8-pin x 2 rows of header pins

Sample code to flash LEDs on XMC2Go

• Document: XMC 2Go - Initial Start-Up Guide 
• Example Code XMC_2Go_Inital_Start_v1.3.zip

Sample code for using P2.7, P2.9, P2.10, and P2.11 as general-purpose ports (GPIOs)

The XMC2Go can be equipped with two rows of 8-pin x 8-pin header pins. If the user is P2.7, Sample code for using P2.9, P2.10, and P2.11 is attached. The file name is "XMC_2Go_Inital_Start_v1.3_P2_7,9,10,11.zip".

Use DAVE's Import function to import "XMC_2Go_Inital_Start_v1.3_P2_7,9,10,11.zip".
In order to use P2.7, P2.9, P2.10, and P2.11, we have added two places in the figure below.

where P2.7, P2.9 cannot be used as an output due to the STD_IN/AN function, as stated in the data sheet.
P2_7_set_mode(OUTPUT_PP_GP);
P2_9_set_mode(OUTPUT_PP_GP);
There is no particular error in the line, but it will not be OUTPUT as specified.
P2.10 and P2.11 are written as STD_INOUT and can be used for input and output.

Also, since AN (Analog input) is the default setting, if you want to use it as a GPIO P2_PDISC you need to set the registers.
(Example)
P2_10_enable_digital();
P2_11_enable_digital();

more than

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/%E3%82%B3%E3%83%BC%E3%83%89%E4%BE%8B/XMC2Go-for-XMC-starters/td-p/642676

Solution: Use Kitprog to Program PSoC 4000 without XRES pin

version 1

Sept 12, 2019.

Several PSoC 4000 chips do not have the XRES pin.  XRES is typically used by Kitprog to reset the chip to acquire a communication path for SWD. 

PSoC 4000 chips (and other PSoC families) can be reset by a Power Cycle.  This means, the chip Vdd must be brought to ground for an amount of time to meet the chip reset spec, while discharging any decoupling capacitors. Then, Vdd is brought up to it's desired operating voltage while also charging decoupling capacitors.  Programming current is approx 3.5mA @5V (reference from Cypress).

Kitprog XRES signal is both an input and an output.  For now, lets examine the output feature.

When PSOC Programmer instructs Kitprog to program a connected target device, Kitprog must first 'acquire' the target chip prior to SWD communications.  (Technically, 'acquire' is part of the SWD definition). Kitprog begins the acquire sequence of events by asserting its XRES signal to logic 0 for 100us.  Kitprog then sets XRES to logic 1 and performs the rest of the acquire sequence.

So, if we can use Kitprog's XRES signal to control PSoC Vdd, we can perform a Power Cycle.

The following criteria are used to perform a successful Power Cycle:

1) discharge the PSoC and decoupling capacitors within 100us

2) provide power to PSoC Vdd before Kitprog acquire sequence times out

3) meet PSoC reset timing

4) use Kitprog SWD (PSoC 4000 only supports SWD initial programming)

5) use PSoC Programmer

6) operate at +5V (+3.3V operation is described later)

7) PSoC not soldered onto pcb, or, PSoC Vdd (with it's decoupling capacitors) can be isolated from pcb circuitry

😎 PSoC SWD pins are available/accessible for connection to Kitprog

What's needed is a buffer circuit between Kitprog XRES signal and PSoC Vdd pin.  This can be implemented in many different ways.  One way is described below.

 
It's assumed the appropriate decoupling capacitors are connected to PSoC (not shown in drawing for simplification). Follow Cypress design guidelines for decoupling capacitors and powering.

The 74HC14 can also be replaced with 74HC00, 74HC32, 74HC08, just about any 74HCxx device that can be wired as a non-inverting buffer (2 invertors in series for example) with 2 (or more) outputs resistively tied together.  For the 74HCxx family, use at least 2 connected in parallel to drive Vdd.

When more current is needed, possibly because the PSoC is on a pcb and there are several devices connected to the common PSoC Vdd, use 74AC14 and connect 1-upto-5 invertor outputs resistively with 11 Ohm resistors.  The 6th invertor in the package is used to drive the 1-upto-5 invertors.  With more than three 74AC14 invertors in parallel, you may need to dampen Vdd to control the overshoot/undershoot (beyond the scope of this discussion).

The 74HCxx or 74AC14 is powered from Vtarg signal.  Both logic families can operate at 3.3V and +5v.  The 74HCTxx and 74ACTxx are only spec's to operate at +5V.

Kitprog can operate from +3.3V to +5V as discussed in PSoC 5LP KIT-059 guide.

Notice the 56k Ohm pull-up resistor attached to Kitprog XRES.  This is needed to prevent Kitprog from entering it's own bootloader code. If omitted, Kitprog will slowly flash its LED as an indicator it has entered bootloader mode.  You can't program PSoC 4000 when this happens.  So, install the 56k Ohm resistor.

For programming PSoC 4000 at +3.3V, a few modifications are needed.  This is documented in Cypress KIT-059 documentation for PSoC 5LP.  The most important mod is to remove diode D1 from the back-side of Kitprog.  Now, connect +3.3V to Vtarg.  Kitprog measures the voltage on Vtarg and adjusts its SWD signal voltages to match. The 74HCxx devices will operate at +3.3V, but might need additional invertors/gates (connected resistively in parallel as shown in circuit diagram) to achieve the necessary sink/source current.

For programming PSoC 4000 below +3.3V with Kitprog, that's an unknown.  There are no voltage/programming spec's for Kitprog so it's not known if it has this capability.  This is where Miniprog3 comes in handy.

What you don't expect...

When programming a blank PSoC 4000 the very first time (remember, it's blank), port pin P1.6 should be left floating, or, connected to a 36k-56k pull-up resistor to Vdd. If any other circuitry is connected, the PSoC 4000 won't come out of its reset state and it won't program (Kitprog won't be able to 'acquire' it).  After PSoC 4000 has been programmed at least once, connections can be made to P1.6. Unknown why this happens.

Cypress recommends to use P1.6 as an output and DO NOT make any type of connection between P1.6 with ground.  Otherwise, PSoC 4000 won't come out of reset state no matter how many times it's Power Cycled.

KEEP THE WIRES SHORT !!!

If the SWD wires connecting Kitprog to PSoC are longer than 10cm, you may have problems with SWD signal integrity.  5cm length works very well.

Be aware of what's connected to PSoC SWD pins when designing a schematic in case it has to be programmed incircuit.

Summary:

Kitprog can be used to program PSoC devices needing the Power Cycle reset method.  It just needs a bit of extra circuitry.  Experiment with different gates/invertors as needed. No guarantee the above circuit will work for all situations, but it's a place to start.  Feel free to modify the buffer circuit.

Details:

PSoC Programmer 3.28.0

Kitprog 1 running firmware 2.21 from version 1 of CY8CKIT-059

CY8C4013SXI-410 (SO-8 package, no XRES pin) datasheet

CY8CKIT-059 PSoC® 5LP Prototyping Kit Guide, Doc. #: 001-96498 Rev. *G

KitProg User Guide, Doc. # 001-96359 Rev. *G

CY8C4xxx, CYBLxxxx Programming Specifications, Document No. 002-22325 Rev. *C

Hi, Community,

The project was created to provide a rudimentary understanding of proximity sensor functionality.
This was worked on in PSoC Creator.

This project is based on CE225691_PSoC4_CapSense_Proximity.
The five elements of the slider electrode on the kit are assigned to the CSD button and they are ganged together to act as a proximity sensor.
The first step is to operate the sensor as a proximity, and when a finger touches the electrode (only SLD1 in this project), it toggles the GPIO to which the LED is connected.
Regarding the ganged button, I was able to assign a function to it as a stand-alone it as well.

In addition, the CAPSENSE Tuner could be launched through the UART connection to check the operation of the CAPSENSE.

Designing the electrodes would be a very tough job, so I decided to try it first with the electrodes in the kit.

Finally, the work for the BUTTON alone could be done by sending a message serially instead of lighting an LED, and I think it could give a lot of ideas to be implemented.

TopDesign & Pin allocation:

NOTE:
LED are externally mounted.
If you want the LED connected to the PWM to light up in reverse of the proximity operation, change the following: change the Output line signal to "Invert output".

Best Regards,
Chihiro Tatebayashi / NEXTY

This is an example of the  8-bit arbitrary signal generator playing DTMF tones on PSoC4200M CY8CKIT-044 Pioneer Board.

Like the previous example,  this project also uses Double-Buffered DMA to update the IDAC8. However, this time the data are being calculated in the real time by DDS, and the IDAC is operated in bidirectional mode, which requires setting IDAC's direction (sign) and magnitude. 

This has several benefits, compared to the previous example:
     - The signal output is centered around Vref (here Vdd/2 was used)
     - The output amplitude has double span (-255 to 255)
     - Using single DMA channel allows for higher update rates

The drawback is that now two bytes have to be populated in the temporary buffer array {CTRL, data}, which consumes more processor clocks. This load, however, is quite low, reaching in current example only ~3% of all processor time.

The Double-Buffered DMA uses intermediate RAM Buffer of size 2N=64 bytes made of two equal halves, to store the data coming from the data source. The DMA1 consists of two chained Transfer Descriptors TD0 and TD1, copying 2 bytes from the Buffer to the IDAC on each clock. Once TD0 finishes copying the data from the first half of the Buffer, it chains to the TD1, which copies data from the second half of the Buffer and loops back to TD0.

Once TD0 (or TD1) is completed, an interrupt is fired, signaling that this Buffer half needs replenishment (while the other one is busy). At this point processor need to fill the half-Buffer with generated waveform, and wait for the next data request, while the Buffer content is being continuously played without interruption.

DTMF tones (F1 + F2) are generated in real-time using two software DDS blocks, which return 8-bit sine waveforms based on the lookup table.

The IDAC is used in bipolar mode, both Source and Sink, controlled by the sign of the input data. The IDAC current is converted into voltage using 3.3k resistor and buffered by the Opamp in the transimpedance mode. The Opamp output is centered around the reference voltage (Vdd/2): Vout = 0.5Vdd +/- 1.0V.

By default the project is configured to start playing waveform on startup and plays each DTMF tone for 2 seconds.

Project attached contains all necessary files. It was tested using both Creator 4.0.

Figure 1. Project schematic. The DTMF data are generated by DDS_1 and DDS_2 on request, and then transferred from the  Buffer to the  IDAC using DMA. The IDAC output current direction is controlled by the sign of the data. The IDAC operates in transimpedance mode using using 3.3k feedback resistor, producing 0.5Vdd +/- 1.0V signal. 

Figure 2. Project annotation using the PSoC Annotation Library v1.0 and KIT-044. The Red LED pin was used for the performance testing; it raises on ISR routine entry, and lowers on exit. The duty cycle on this pin shows the processor load (~3%). The reference voltage is "stolen" from the hidden Pin_5[0], which is connected to the Vdd/2 onboard source. For sound generation, the output can be directly connected to the headphones with combined impedance of 64oHm (32+32). Capacitors shown are optional and don't affect output significantly.

Figure 3. Output waveform for DTMF tone 697Hz + 1209Hz. Yellow - DTMF generator output, centered around Vdd/2. Cyan - test digital pin, raising on DDS routine entry, and lowering on exit. The half-Buffer length to be populated is 32, and DMA sampling clock is 32 kHz, which results in 1 kHz ISR rate. DDS routine calculations take about 28usec, resulting in  processor load of less than ~3%.  

Figure 4. FFT example of the DTMF tone 697Hz + 1209Hz. 

Hi, Community,

Here is an example code to measure power consumption of PSoC4000S without entering low power modes like Deep Sleep. Please note that in order to perform the experiment, you will need to remove resistors R22 and R23 on the CY8CKIT-145 evaluation board.

And I removed the jumper on J3 and measured it using the current mode of a tester.
The system frequency of the PSoC4000S is set to 24MHz.
The result shows that the power consumption of the PSoC4000S, with VDD = 3.3V, is approximately 4.8mA.

Was my expectation that it would be about the same as IDD8 correct... ?

I attached the main.c file. Please add it to an empty project.
The TopDesign is as shown in the image.

Best Regards,
Chihiro Tatebayashi / NEXTY

This is an example of the  8-bit PCM audio playback on PSoC4200M CY8CKIT-044 Pioneer Board using Double-Buffered DMA.

Unlike the previous example, which used single-buffered DMA to update the IDAC8, this project is using a Double-Buffered DMA to transfer the data. This has several benefits, compared to previous example:
     - No limitation on the audio data size.
     - Possibility to mix data from several data sources or manipulate the data
     - Seamless data output (no interruptions).

The drawback of the approach is certain processor load, which has to repeatedly populate the Buffer with fresh data. This load, however is much lower compared to using direct interrupt write without DMA. 

The Double-Buffered DMA uses intermediate RAM Buffer of size 2N=64 bytes made of two equal halves, to store the data coming from the data source. The DMA1 consists of two chained Transfer Descriptors TD0 and TD1, which copy data byte-by-byte from the Buffer to the temporary RAM location (TMP). Once TD0 finishes copying the data from the first half of the Buffer, it chains to the TD1, which copies data from the second half of the Buffer and loops back to TD0. In this demo, the Buffer size is 64 bytes. Actual size should be set depending on the latencies of the processor, but 128+128 is typically a good size. Project dataflow:

Once TD0 (or TD1) is completed, an interrupt is fired, signaling that this Buffer half needs replenishment (while the other one is busy). At this point processor need to copy fresh portion of the data from the data source (here it is a FLASH), and  wait for the next data request, while the Buffer content is being continuously played without interruption. 

The data source can be RAM, FLASH, SD card, or processor generated data (sine, etc.).  

To get the data to the IDAC8, the 8-bit data is first copied by DMA1 from the Buffer into intermediate (16-bit) location in RAM, where the MSB keeps IDAC control settings, and LSB has the data. The DMA2 then transfers 2 bytes {MSB, LSB} to the IDAC8 control register. Such intricate scheme is required because the DMA transfer to the IDAC is always 16-bit, thus the attempt to send only the data byte wipes off the IDAC control settings.      

The project is configured to play on startup the Sawtooth test waveform  in the continuous loop. Optionally, it can be configured to play a single time by enabling the SINGLE_SHOT directive.

The audio data are stored in the PSoC FLASH in 8-bit unsigned PCM format. Attached project includes several test PCM audio files in 8-bit unsigned format:
sawtooth_8-bit_S.h                             - test sawtooth, 8-bit, Unsigned (size= 256 bytes)  
smb_world_clear_5k5_N_U.h        - Super Mario theme, 5.512kHz, Normalized, Unsigned (size=33600 bytes)
smb_world_clear_11kHz_N_U.h   - Super Mario theme, 11.025kHz, Normalized, Unsigned (size=65536 bytes)
smb_world_clear_22kHz_U.h        - Super Mario theme, 22.05kHz, Unsigned (size=65535 bytes, clipped)

The WAV files have been converted to the C code using  WAVtoCode v1.1.1 by Colin Seymour. The original WAV data have been Normalized to fill the entire 8-bit scale, which has increased the dynamic range.

Project attached contains all necessary files. It was tested using both Creator 4.0 and 4.4.

Credits:
     WAVtoCode v1.1.1 by Colin Seymour:         https://colinjs.com/software.htm#t_WAVToCode

Figure 1. Project schematic. The PCM data are copied from the FLASH to the Buffer by code, and then from Buffer to the  IDAC using chained DMA. The IDAC is configured as a Source. The IDAC current is converted into voltage using 3.3k load resistor buffered by the Opamp in the follower mode, producing 0-1V signal at full scale.. For sound generation, the output is directly connected to the headphones with combined impedance of 64oHm (32+32).

Figure 2. Project annotation using the PSoC Annotation Library v1.0 and KIT-044. The Opamp output is directly loaded on the headphones with combined impedance of about 64oHm (32+32).

Figure 3. Output waveform on startup. The test data is Sawtooth, 256 points per period, played in the loop continuously.

Figure 4. Sawtooth waveform output when configured for a SINGLE_SHOT. The number of data points is 256, played once. After the end of data, the output can be set to some pre-defined value (here is 127).