DA8xx Hardware Bring-up

Introduction

This page describes H/W bring-up procedure for DA8xx SDK.

• Target reader of this page is the user who checks & validates his original hardware platform.
• Basically this page is not needed for the user who just uses standard EVM.
• Those information following is needed once after finish assembling the PCB board.

Check Items for bring-up

SDRAM testing

sdram_test project provide the utility which check the connection between DSP & SDRAM.
It is released as sdram_test_yymmdd.zip which is a part of the SDK release.

SDRAM test Usage

1. Import sdram_test project

   Once you decompress the sdram_test_yymmdd.zip on the T:\ drive, project will be in the T:\pa\sdk\eou3\sdram_test folder.

2. Build sdram_test project

   Note that, "sdram_test.c" in the sdram_test project can be modified below variables. Should be changed depends on each user's H/W.

   • EXTERNAL_MEM_SIZE
     • Defalut size :16*1024*1024[bytes] = 128Mbit. when 64Mbit is used, should be changed as 8*1024*1024.
   • EXTERNAL_MEM_START
     • 0xC0000000 : Start address for EMIFB, which is SDRAM dedicated memory bus (default)
     • 0x40000000 : Start address for EMIFA, which is general purpose memory bus (SDRAM available)

3. Load & Run the sdram_test.out which is built at above 1.
   • Maybe you need to modify the GEL_file depends on your specific H/W configuration. In that case, please refer Customizing_DA830_GEL_files

4. Once this utility starts, the message like below will appears on the stdout windows on CCS:

   Testing 4.000000 (0x00400000) MWords starting at 0xc0000000

   Testing 16.000000 (0x01000000) MBytes starting at 0xc0000000

   (counter += 0x00000004) XOR 0xc0000000 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0x00000001) XOR 0x00000000 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0xffffffff) XOR 0xaaaaaaaa test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (Walking 1) XOR 0x00000000 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (Walking 1) XOR 0xffffffff test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0x00000001) XOR 0xffffffff test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0x00010001) XOR 0x00000000 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (Walking 1) XOR 0x0f0f0f0f test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (Walking 1) XOR 0xf0f0f0f0 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (periodic random) XOR 0x00000000 test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   (periodic random) XOR 0xffffffff test loop #0: There were 0x00000000 errors out of 0x00400000 words -- good

   Cumulative number of errors: 0

   (counter += 0x00000004) XOR 0xc0000000 test loop #1: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0x00000001) XOR 0x00000000 test loop #1: There were 0x00000000 errors out of 0x00400000 words -- good

   (counter += 0xffffffff) XOR 0xaaaaaaaa test loop #1: There were 0x00000000 errors out of 0x00400000 words -- good

   ......

   ...

   Number of above "Loop #.." will increment forever, so it can also use for endurance test.

Audio Echo Using DAP

Audio Echo provides the check program, which can check the audio codec device, such as ADC, DIR, DAC and so on.

Audio Echo Usage

1. Import echo project

   There is a "Release_echo" configuration in the "pa_i14_evmda830" project, which is located in the T:\pa\f\s19\i14\evmda830 folder.
   So please set Active Build Configuration as Release_echo

2. Build echo project

   Echo program doesn't have a feature to change DAP module dynamically.
   So when you build the project, you have to change DAP definition as the device now you want to check.

   • When you try the Standard EVM or custom H/W which uses same I/O configuration, you can select the default DAP, such as :
     • DAP_E17_RX_DIR
     • DAP_E17_RX_ADC_SLAVE
     • DAP_E17_RX_ADC_6CH_48000HZ
     • ...and so on
   • When you use your specific DAP configuration, you should customize dap_e17.c (usually rename such as dap_cust.c) depends on McASP usage:
     • Please refer the Audio_I/O_Customization for details.
3. Load & Run echo.out, which is built at above procedure.
4. Provide any sound source on the input DAP device you set(DIR, analog 6ch, e.t.c.)
5. Connect Speaker to output DAP device you set, then listen to the output(Analog 8ch, DIT, e.t.c.)

Control Echo Using DCS6(SPI, I2C & UART)

SDK Release includes control_echo_yymmdd.zip which provides the check utilities for control line connection, such as SPI and I2C, used in the DCS6.
When you try SPI or I2C control echo, what Host Micro has to prepare, is written in the command sequence as below: .
When you try UART control echo, please see there about UART echo.

Usage - DSP as slave

1. Import echo project

   Once you decompress control_echo_yymmdd.zip on the t:\ drive, there will be echo project in the T:\pa\sio\dcs6\echo\echoProject folder.

2. Build the echo project (SPI0/1, I2C0/1 & UART0/1/2)

   By changing source file echo.c in the project, you can customize control path depends on your H/W, like below:

   • I/O port selection:
     • RXTX_DEVICE_SPI0 _or_ RXTX_DEVICE_SPI1
     • RXTX_DEVICE_I2C0 _or_ RXTX_DEVICE_I2C1
     • RXTX_DEVICE_UART0 _or_ RXTX_DEVICE_UART1 _or_ RXTX_DEVICE_UART2
   • Configuration for each I/O port:
     • SPI_MODE(number of pins), SPI_CLEN(length of character), SPI_POL(clock polarity) & SPI_PHA(clock phase)
     • I2C_SLAVE_OA(Address), I2C_SLAVE_PSC(clock prescaler), I2C_SLAVE_CLKL(clk low-time) & I2C_SLAVE_CLKH(clk high-time)
     • UART_DIV_SEL(Div for baud rate), UART_MDR_SEL(clock oversampling) & UART_FL_SEL(Fifo level)
   • Please refer to T:\pa\sio\dcs6\echo\echo.html for more details.
3. Load & RUN the echo.out, which is built by above step.
4. Then start Host micro procedure below .

Usage - Master Micro for SPI or I2C

Once echo project is loaded & runs on DSP, Host Micro has to follow the command protocol as below:

1. Send Zero

   • to get the DSP start command "0x80", which means 128 data will be sent following this command.

2. Send zero 128 times

   • to get the incrementing data, as 0x00,0x01,...,0x7F

3. Send "0x80"

   • to tell DSP should get following 128 data after this command.

4. Send back 128 incrementing data

   • as 0x00, 0x01,...., 0x7F. During sending those data, host will get the zeros.

5. Back to 1. , if needed.

• When you use I2C, default slave Address is: I2C0 - 0x28, I2C1 - 0x29, and default Data rate is 378 kbps (when DSP runs 300Mhz)
• After DSP gets 128 incrementing data, DSP immediately starts verification, and count up failure internally.
• DSP also counts up how many time those above sequence are done. So this can be also used as endurance test.

Command sequence of the DCS6 Echo

Usage - Master Micro(or PC) for UART

• 　Basically, UART echo performs echo back of the received character.
• Send the character, then send CR+LF (i.e. 0x0A & 0x0D). Once received CR+LF, slave DSP will start echo back the all data which is stored in the buffer.
• When the received data is alphabetical character, it changes lowercase character to uppercase character, or uppercase character to lowercase character, then echo back.
• default serial port configuration is below:
  • baudrate is 19200bps
  • data length 8
  • stop bit is 1
  • no parity bit
  • no H/W flow control

Please see below figure to imagine the behavior of UART echo.

Echo back of this UART Echo

Flash driver for SPI flash

SDK Release includes pa_bdk_da8xx_yymmdd.zip , as the "flashtest" project, which check the SPI serial Flash connection & device availability.

Usage

1. Import project

   Once you decompress "pa_bdk_da8xx_yymmdd.zip" on the "T:\" drive, you can find that utility under the T:\bdk\spiflash\flashtest folder. So please import the project from there.

2. Build flashtest project
   • Note that, command set of each serial flash device is not unique.

   Even though, as a result,usually similar command set are hired by every major serial flash providers, such as STM, ATMEL, WINBOND, SST & so on.

   • DA830 Standard EVM uses 32mega-bit SPI serial flash "W25X32VSFIG" produced by WINBOND.
   • JEDEC defines JEDEC-ID, which shows the Manufacture & Device series.

   So basically all serial Flash device has specific Manufacture ID and Device ID, then the Flash driver can switch the properly command set for each device.

   • Unfortunately, this flashtest utility has just one command set today. So user may have to prepare device specific command set for serial flash device which he uses.

   To change the flash driver, please refer following section,SPI Driver Customization.

   • After done all required modification for each flash device, build the project.
3. Load & Run the flashtest.out, which was built above procedure.
   • Maybe you need to modify the GEL_file to select control lines, which will be used in your specific H/W configuration. In that case, please refer [Customizing_DA830_GEL_files|Customizing_DA830_GEL_files]
4. Once utility started, messages like below appears on the stdout window on the CCS.

   Manufacturer ID : 0xef Device ID : 0x15

   Writing to flash

   Verifying the flash

   Flash driver is good :)

5. Above message appears when there is no trouble. But if there is any trouble, the error message will appears like that.

   Manufacturer ID : 0xef Device ID : 0x15

   Writing to flash

   Verifying the flash

   [3418256] 0xe8 = 0x54

   [3418257] 0x4a = 0xe

   [3418258] 0x2 = 0x7d

   [3418259] 0xc0 = 0xbf

   Flash driver is not good :(

SPI Driver Customization

This chapter describe the basic idea to customize the SPI driver.
Basically, there are only 2 files which are needed to customize as:

• da8xx_spi.h,
• spiflash_xx.c (xx should be vender name of flash). spiflash_wb.c (wb is abbreviation of WINBOND )is provided as example of TI EVM

Recommended Customization Procedure of SPI flash driver

1. spiflash_wb.c contains all the basic flash specific implementation. So create a new file spiflash_xx.c, which is specific to customer and copy content of spiflash_wb.c.
2. Update the various flash commands and flash declarations based on the flash specific data sheet. All SPI serial Flash commands are implemented as specific functions, So all the below functions are needed to be updated as per flash command definition.

Functions which will be customized

1. SPIFLASH_ManufacturerID ()
   • Function to read Manufactured ID of the flash. Data format is not unique among different venders.
   • spiflash_wb.c use 90H command for this feature, and some SPI flash product also use 90H, so it may not be needed to customize.
   • To get those device information, using JEDEC-ID Command, 9FH is good idea.
   • When JEDEC-ID command is used, you may have to use additional READ-ID command to get extended information about that device.
2. SPIFLASH_DeviceID()
   • Function to read device ID of the flash. Data format is different among venders.
   • Usually same manner to get this ID as above ManufacturerID.
3. SPIFLASH_Status ()
   • Function to read the SPI flash device status.
   • Usually, 05H is used for this command(not definitely). So may not need customize.
   • Contents of status register should be different among different device.
   • Even though usually includes, such as BUSY, Write Enable, and so on.
4. SPIFLASH_Read (void *pDst, void *pSrc, Uint32 nlength)
   • Function to read the content of flash from pSrc to pDst of size nLength bytes.
   • W25X32VSFIG has a sequential read capability, so in the spiflash_wb.c, sequential read of SPI flash is implemented as default.
   • READ Command is usually 03H(not definitely, but very common). BUT some device requires different command to read out sequentially. So please read datasheet of serial flash carefully.
5. SPIFLASH_BlockErase (Uint32 blk_no)
   • Function to erase the content of block number specified by blk_no.
   • Configuration & conbination of Blocks are device specific, so please read datasheet for each flash device carefully.
6. SPIFLASH_Write (void *pDst, void *pSrc, Uint32 nlength)
   • There are 2 types of SPI serial flash like below:

   • Block Programing device (W25X32VSFIG is belong to this group)
   • Byte Programing device

   • Usually both those 2 types of devices use same "02H" command code for device programing. So carefully customize this command.
   • Function to write content to flash from pSrc to pDst of size nLength bytes. Flash erasing (and sometimes Flash programing) must be performed at the block level.
   • Each block of flash is programmed in terms of page size, on the W25X32VSFIG device(default source code).
7. SPIFLASH_Unlock()
   • Some vender provide the device which is set “write protection” at default. In this case, you need to prepare unlock module.
   • Usually, that lock is cleared by the modifying any bit(s) on the status register, so please read datasheet carefully.