# Project Name：YTMEVB_Demo


---


## Function description

This project is designed to demonstrate the MCAL driver modules typical configuration and usage:

- **Gpt**
This demo initializes Gpt with 3 channels. Channel 0 is used to generate the 5ms task interrupt, channel 1 is used to service Wdg_180_Inst0, channel 2 is used to service Wdg_180_Inst1.

- **Pwm**
This demo initializes Pwm with 3 channels. Channel 0 is used to drive RED LED, channel 1 is used to drive GREEN LED, channel 2 is used to drive BLUE LED.The ADC0 AN1(the RP1 in EVB) and AN2(the RP2 in EVB)  are usd to control the BLUE and GREEN LED(**LED8**) brightness with PWM.

- **Wdg**
This demo initializes the Wdg_180_Inst0 (WDG) in window mode and Wdg_180_Inst1 (EWDG) in window mode, then triggers the Wdg_180_Inst0 every **200ms**, and triggers the Wdg_180_Inst1 every **500ms**. If the Wdg_180_Inst0 is not triggered within 0-500ms, Wdg_180_Inst0_Callback will be called then the system will reset. If the Wdg_180_Inst1 is not triggered within 400-1000ms, Wdg_180_Inst1_Callback will be called.

- **Adc**
This demo initializes Adc with two HW instances and 4 groups. The group0 to group2 is assigned to ADC0 with interrupt, and the group2 is assigned to ADC1 with DMA. VDD25 is collected by group1 and group2.The results of each group converted are compared, and if the difference exceeds ±50mV, the Adc0_Vdd25DiffOutofRangeCnt is incremented by 1. 

  - Adc conversion results control the PWM duty. The RGB **LED8** is driven by PWM, the duty is controlled by the ADC conversion results.
    *  Blue LED is driven by AN1_RP2(on Rev.A EVB) or AN2_RP2(on Rev.A EVB)
    *  Green LED is driven by AN2_RP1(on Rev.A EVB) or AN1_RP1(on Rev.A EVB)

- **Fls**
This demo configures 44kByte DFLASH(the hw address 0x40000 to 0x4AFFF) for Fee.

- **Fee**
This demo configures three Fee blocks belong to two groups. The block named 'Fee_PowerOnDataBlock' used to save power on times and MCU reset reason, it's read and written when init. The block named 'Fee_DTCDataBlock' is written together with 'Fee_PowerOnDataBlock'. The block named 'Fee_AppDataBlock' is written every 100 seconds. 

- **Spi**
This demo initializes Spi_0(SPI0 with 1Mbit/s) with sequence 0, and transfers 32 bytes(0x00 to 0x1F) data with DMA.
**Note**: Please double check and ensure the **SIN**(PTE1/**H4-18P**) is connected with the **SOUT**(PTE2/**H4-10p**) for the test.

- **I2c**
I2C0 configuration in master mode for reading and writing external EEPROM data on the EVB, asynchronous mode with periodic read and write cycles of 1 second each, fixed writing of 8 bytes of data (0x00 to 0x07).

- **Icu**
  The demo configures 3 Icu channels:
  1. ***Icu_Ch0*** requires input a 10KHz PWM signal to **PTC12** pin for signal measurement test.(Or ***OCU output 10KHz*** waveform can also be short-circuited for the test)
  2. ***Icu_Ch1*** connected to **SW3**, and it toggles the user **LED_RED**/**LED7** once the **SW3** is pressed. after **SW3** Press Count ***10*** times, the MCU goes to **PowerDown** mode.
  3. ***Icu_Ch2***(**H2-5P**) short-circuited to SW2(***J19-2P***) to test, and it toggles the user **LED_RED**/**LED7** once the **SW3** is pressed. **SW2** press and the MCU wakes up from ***PowerDown*** mode.

- **Ocu**
  **PTC28/eTMR0_Ch0** is configured as a Ocu channel to output a **10KHz** square wave.

- **UART/CddUart**
***LINFlexD2*** is configured to work in UART mode with <u>115200 baudrate. 1bit-start, 8bit-data, 1bit-stop, no parity</u>.
  It is used to print the MCAL driver modules test result/log as bellow screenshot:
  ![UART_LOG](./UART_Log_print.jpeg)

  **Note**: 1. the UART test is called in **500ms** task; 2. the **J26** should be shorted to ensure the UART-to-USB to work well via a type-C cable plugin to the **USB1** port with your PC for message monitor(a serial terminal program is recommended).

- **Lin**
The demo configures the two onboard LIN interfaces - **LIN1(LINFlexD0)** as a **master**/***Door*** node and **LIN2(LINFlexD1)** as a **salve**/***Window*** node with **19200** baudrate for the test.
The two LIN PHY/transceivers are configured as enabled by default(via driving the SLP_N as HIGH(logic 1)) for the two LIN bus.
The Lin test is performed in a **200ms** task:
  1. The master node firstly sends out **10** master-response LIN message frame with ID = **0x10 to 0x19** and data of the follow 8 byte arrow correspondingly(<u>The slave node receives the master-response LIN message frame and checks the received data correspondingly</u>):
  ```c
    uint8 lin_Master_txDataMatrix[10][8] = {
      {0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x01},
      {0x31, 0x42, 0x53, 0x64, 0x78, 0x69, 0x37, 0x02},
      {0x21, 0x92, 0x03, 0x13, 0x22, 0x06, 0x07, 0x04},
      {0x31, 0x32, 0x04, 0x04, 0x33, 0xF6, 0x07, 0x08},
      {0x41, 0xB2, 0x05, 0x33, 0x05, 0xd6, 0x57, 0x10},
      {0x77, 0xA2, 0x06, 0x04, 0x7D, 0xE6, 0x07, 0x18},
      {0x99, 0xF2, 0x07, 0x58, 0x05, 0x06, 0x67, 0x20},
      {0xBB, 0xE2, 0x08, 0x32, 0x8F, 0xD6, 0x07, 0x28},
      {0xDD, 0xD2, 0x09, 0xA4, 0x05, 0x06, 0xB7, 0x30},
      {0xFF, 0xC2, 0xAA, 0x24, 0x66, 0xA6, 0x07, 0x40},
    };
- 2. The master then sends out **10** slave-response LIN message frame with ID = **0x20 to 0x29** and and slave node response the data of the follow 8 byte arrow correspondingly:
  ```c
    uint8 lin_Slave_txDataMatrix[10][8] = {
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x11, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x22, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x33, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x44, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x55, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x66, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x77, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x88, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x99, 0x10},
      {0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0xAA, 0x10},
   };
- **Can**
The demo configures two CAN controller instances - CAN1(FlexCAN1) and CAN2(FlexCAN0) with **500Kbit/s**(***81.25%*** sample point) + **2Mbit/s**(FD data field,***83.33%*** sample point) bitrate(with **ISO-CANFD** enabled) and enable the correspondingly CAN PHY(transceiver) for the test.
  - the two CAN bus are connected(**J12** <-> **J7**) to the same CAN bus and TX/RX some CAN 2.0 and CANFD message frames with each other for the test.
  - if the controller meets the CAN bus error and enter the bus-off, it will recover automatically.
  - The CAN **controller** and **HardwareObject** as well as the TX/RX message box are configured as below:
  ![Can_Controller_and_Obejct_MapConfig](./Can_Controller_and_Obejct_MapConfig.jpeg)
  -The CAN TX and RX message buffer(MB) and Rx filter are configured as below:
  ![Can_Tx_Rx_MB_Filter](./CAN_TxRx_MB_Filter_Config.jpeg)
  **Note**: The three header of the onboard jumper **J16** and **J11** on the EVB are required be shorted for the test.

- **Crypto**
  The demo illustrates services running with the processing type ***synchron*** or ***asynchron***. It also shows how to operate services in ***SingleCall*** mode (separately calling ***START***, ***UPDATE***, ***FINISH***) and in ***StreamCall*** mode (calling ***START***, ***UPDATE***).

---

- **Note**: The global macro `MCAL_ENABLE_USER_MODE_SUPPORT` and `MCAL_SCHM_LITE` are added for VSCode + Ninja + CMake with GCC/IAR/Keil toolchain, if IAR/Keil IDE project is used for the build/compile, manually add these macros and sub-floders of the `app` to the project settings are required.
- **Tips**: Special care should be taken for the VSCode + Ninja + CMake with `Keil/ARMCLANG v6.18.2`, linker option `--legacyalign` maybe required to ensure the functions in the `ramcode` section are remapped as expected in the `CMakeLists.txt` file under the root directory.
  ```c
  target_link_libraries(${project_elf} "--entry Reset_Handler;--scatter=../board/yt_linker.scf;--legacyalign")
  ```
---


## Setup

+ ***Step1***: Open the YTMEVB_Demo.yct with the YCT tool, config the toolchain per your required(by default, the VS code + GCC are used)
+ ***Step2***：Generate the codes， you can change the configurations if needed(to adapt to your own HW design), if so, please ensure all the modifications are OK with no any errors exist before generating the code.
+ ***Step3***: Open the generated project with VS code/IAR/Keil IDE per your selected.
+ ***Step4***: Compile the project, power on the EVB and download it to the EVB via the available debugger, such as a J-Link debugger probe.
+ ***Step5***: At last, enjoy the demo example.
  
---
## EVB hardware connection requirements
User should double check the hardware connection requirements as below:
![EVB-HW-connection](./EVB_HW_Connection.jpeg)

---

## Hardware requirement
+ **EVB**: YTM32B1MD1-EVB-Q100-Rev.A/B
+ **Debugger**: J-Link HW v9 or later with YUNTU `YTM32B1MD1` patch(support package) installed.

**Note**: Please check the version number at the bottom of the EVB. If it is `YTM32B1MD1-EVB-Q100-Rev.A/B`, please use the example projects ending with `_RevA` for `Icu_Demo`.
---

## Software requirement

+ **Config & Code Generation Tool**
  + **MCAL**: Yuntu Config Tool(YCT) v2.7.0 or later version
+ **Compiler Toolchain**
  + **GCC**: GNU GCC v10.3 or later version
  + **Keil/MDK**: ARM Keil/MDK v5.36 or later version(`armclang v6.18.2` is recommended to be used as the compiler)
  + **IAR**: IAR v9.50 or later version
  + **VS Code**: Microsoft Visual Studio Code IDE v1.76 or later version(C/C++ support, GNU toolchain, CMake v3.25, ninja, Cortex-Debug extensions installation required)
+ **Debugger driver**
    + **J-Link**: SEGGER J-Link v7.82 or later version, YUNTU `YTM32B1MD1` patch(support package) installation required.
    + **Ozone Debugger tool**: SEGGER Ozone v3.28 or later version.

    ***Note***: **YTM32B1MD1** patch install required which can be obtained via **YCT** or contact ***YUNTU sales/FAE team***.

---