can't UART boot BF706

Hello everybody,

I am developping a custom board for ADSP-BF706 connected to Raspberry Pi, and I am not able to boot from UART.

First mistake of mine was to connect the Raspberry Pi UART port to DSP UART1 instead of UART0 (default boot port).

In future designs I will connect to UART0 obviously, but for this one I launch debugger and call to adi_rom_Boot to boot from UART1:

#include <sys/platform.h>
#include "adi_initialize.h"
#include <stdio.h>
#include <bfrom.h>
#include <defBF70x_rom.h>
#include <cdefBF70x_rom.h>

void main(void)


	uint32_t command = (0x0 << 16) + (0x0 << 15) + (0x1 << 8) + (0b0 << 6) + (0b0 << 5) + (0b1 << 4) + (0x3);
	adi_rom_Boot(0x0, 0x0, 0x0, 0x0, command);


When I use autobaud detection ('@' byte), DSP UART1 response has sense, but if I write all the boot stream (generated by CCES in ASCII) nothing happens, the DSP does not boot as expected.

What am I doing wrong?

Thanks in advance,


  • 0
    •  Analog Employees 
    on Nov 1, 2019 8:57 AM 11 months ago

    Hi Diego,

    Yes, your understanding is correct. By default following boot modes are supported on Power on Reset in ADSP-BF70x:

    SYS_BMODE Setting

    Boot Mode


    No Boot/Idle
    SPI2 Master
    SPI2 Slave
    UART0 Slave

    In order to change the default boot mode say SPI1 instead of SPI2 for master boot on Power On Reset, this can be achieved by programming the dbootcommand for SPI master in the OTP space referenced by ADI_ROM_OTP_BOOT_CMD_INFO inside ADI_ROM_OTP_BOOT_INFO structure in cdefBF70x_rom.h file.

    Considering your case, I understand that you are intending to use ADSP-BF706 as Slave. Your Host is Raspberry Pi. You are able to send the loader stream, but the Slave boot does not boot. Please correct if my understanding is wrong.

    1. When you say, "When I use autobaud detection ('@' byte), DSP UART1 response has sense,", how did you confirm that the slave has recognized the '@' character?
    2. What is the baudrate you have set for the transfer?
    3. Has the Host been acknowledged from Slave after sending '@' character. The host is requested to not send further bytes until it has received the complete acknowledge string.  The acknowledgment consists of 4 bytes: 0xBF, UART_CLK [15:8], UART_CLK [7:0], 0x00
    4. Can you share the connections between Master and Slave? A simple diagram will be helpful.
    5. Did you get a chance to test with ADSP-BF706 as master and another BF706 as Slave? If not, is it possible for you to test it? I've an UART Host code in my repository. This was tested on ADSP-BF707 EZ-kit as Master and another ADSP-BF707 EZ-kit as Slave. Please find attached code and see if this could help.

    Anand Selvaraj.

  • Hi Anand,
    Thanks for your response.

    SYS_BMODE is set to 11 (UART0 Slave).
    The sequence is the following:
    - I turn on the BF-706 and the current consumption is 30 mA.
    - Then, I launch the debugger (ICE-1000) with the previous code that uses adi_room_Boot and current increases to 90 mA. I stop debugging session and unplug the debugger.
    - After sending the '@' character, I receive 4 bytes (0xBF, UART_CLK [15:8], UART_CLK [7:0], 0x00)
    - I transmit the entire boot loader stream and the current consumption increases till 120 mA, but the DSP does not perform as expected (for instance, SPI communication).

    I readed about OTP, but for this simple test I prefer to use adi_rom_Boot together with the ICE-1000, if it is possible.

    Answering your questions:
    1 - Using an oscilloscope the digital signals are correct, and the slave responds with the expected 4 bytes.
    2 - I try several baudrate (4800, 9600, 19200, 57600, 115200, 230400) and the results are always the same.
    3 - I receive the 4 bytes correctly. With baudrate 4800 the UART_CLK value is 1000, while a baudrate of 9600 produces a UART_CLK value of 500.
    4 - Master and slave are directly connected, without pull-up resistors. Slave RTS is also connected to Master CTS.
    5 - I am going to take a look on your code.


  • I have solved my issues by passing UART0 with UART1 with small wires, and booting normally via UART.

    Furthermore, Raspberry Serial Console was enabled and interfered with the Serial Port, corrupting the data packets.



  • 0
    •  Analog Employees 
    on Nov 8, 2019 11:47 AM 11 months ago in reply to dgaston91

    Hi Diego,

    Thanks for the update. Glad to know that the issue is resolved.

    Anand Selvaraj.