• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 2285 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to increase C5535 on-chip bootloader UART baud rate?

Jun Cao74
Prodigy 100 points


Our system has 2 processors. The master processor is able to boot TI C5535eZdsp through UART. However, the C5535eZdsp bootloader sets up to receive data at UART baud rate of 57600. Loading DSP FW takes about 30 seconds. We need to decrease the loading time to less than 10 seconds. My questions are:

  1. My UART boot experiment was done through C5535eZdsp board. When we use C5535 DSP to build our own application board, the system clock will be 16.384 MHz. Based on below C5535 DSP on-chip bootloader document:

• CPU Clock setup

– If CLK_SEL = 0, the bootloader powers up the PLL and sets its output frequency to 12.288 MHz

(multiply 32 768 Hz RTC Clock by 375).

– If CLK_SEL = 1, the bootloader bypasses the PLL and uses CLKIN. Note that CLKIN is expected to be 11.2896 MHz, 12.0 MHz, or 12.288 MHz.

Then on our board the bootloader baud rate will be 57600 * 16.384 / 12 = 78643.

Is my calculation correct?  

2.   Besides changing DSP CLKIN frequency, is there other way to increase C5535 bootloader UART baud rate? We cannot modify C5535 on-chip bootloader. However, if some other SW / HW setting affect the baud rate, we may be able to change the setting to increase the UART baud rate. For example C5535 bootloader document (sprabl7a.pdf) tells us: To use UART boot, the ezdsp5535 board DIP SW3 should be set to CLK_SEL = OFF and UART_BUFF_EN = ON. Do you know what is the differences to set UART_BUFF_EN = ON or OFF?  

3.      My last choice is writing a “fast UART boot loader” to decrease the UART loading (DSP FW) time. That is first let the C5535 on-chip bootloader to load “fast UART boot loader”. Then let the “fast UART boot loader” run to load DSP FW. If TI support can provide “C5535 on-chip bootloader source code”, that will be great. If anyone can provide similar UART receiving source code, reference document or suggestions, that will also help me a lot. I highly appreciate.

Thanks!

 

Jun

  • 0
    TI__Guru**** 219597 points
    Moving to the C5000 Ultra Low Power DSP Forum.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 100 points

    Thanks, Ryan.  Hope some one will see my post and answer my questions.

  • 0
    TI__Mastermind 30170 points

    Hi Jun Cao,

    After the bootloader polls SPI, I2C, MMC/SD, etc., it reconfigures the PLL for a SYSCLK of about 36MHz (CLKIN * 3 if CLK_SEL is high).

    The bootloader configures the UART baud rate with a divisor of 40 in UART_DLL and UART_DLH registers.

    The resulting baud rate = (SYSCLK / 16) / divisor.

    40 = 0x0028 (decimal to hex)
    UART_DLL = divisor & 0xFF; // = 0x28
    UART_DLH = (divisor >> 8) & 0xFF; // = 0x00

    The baud rate of 57600 baud is achieved with 12.288MHz CLKIN
    With 12MHz, the baud rate is actually 56250 baud, but UART can tolerate some baud rate error.
    With your 16.384MHz CLKIN, you can expect the baud rate to be 76800 baud.

    One trick you might be able to play is to use the -reg_config parameter with hex55.exe when you generate the boot image .bin file from the COFF .out file. This allows you to write to registers before copying the whole bootimg contents.

    However, how will the host processor know to change baud rates? I think you will need to write to the registers of a GPIO first that is connected to the host processor and wait some delay so that both host processor and the C5535 switch baud rates at the same time.


    -reg_config 0x1C06,0x#### (GPIO DIR1)
    -reg_config 0x1C0A,0x#### (GPIO OUTDATA1)
    -reg_config 0x1B10,0x000D (UART DLL = 13 for 236308 baud, assuming 16.384MHz CLKIN)
    -reg_config 0x1B12,0x0000 (UART DLH, bootloader already set to 0, can omit)

    Refer to 7.2.8 UART Initialization in the C5535 TRM - http://www.ti.com/lit/ug/spruh87h/spruh87h.pdf
    And refer also to 13.2.1 Invoking the Hex Conversion Utility From the Command Line in the C55x Assembly Language Tools User's Guide - http://www.ti.com/lit/ug/spru280i/spru280i.pdf

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 100 points
    Mark:

    Thank you very much for providing me great idea and implement detail. You are the true expert. As you mentioned, I have to make sure “both host processor and the C5535 switch baud rates at the same time.” Please further check my below approach.
    1. My boot image / DSP FW
    word 1 Boot Signature (16-bits)
    word 2 & 3 Entry Point
    word 4 2 (Register Configuration Count)
    word 5 0x1B10 (UART DLL)
    word 6 0x0D (UART DLL value)
    word 7 0xFFFF
    word 8 0xF888 (delay)
    word 9 Section 1 word count
    ….
    word N 0000 (end of boot image)
    2. Host started baud rate = 76800 (when DSP board CLK_SEL is high; CLKIN is 16.384 MHz)
    3. After send first 8 words, host changes baud rate to 236308 baud and give some delay for start using new baud rate.
    4. If the delay of 0xF888 is not enough for bootloader change baud rate, host adds additional delay
    5. Host continues sending out the boot image.
    Please also check
    1. C5535 DSP UART can work on 236308 baud (not over its limit)
    2. Changing DLL does not require reset – restart UART
    3. The Host having longer delay than DSP delay will not cause problem, since boot loader UART is waiting for “START bit”.
    Your solution will be my first choice (simple and fast). However, before I can really implement, I would like to keep my post for a while.

    Best regards!

    Jun Cao
  • 0 in reply to Jun Cao74
    TI__Mastermind 30170 points

    Hi Jun Cao,

    Your boot image looks reasonable. Did you create it with the hex55.exe utility, using reg_config flags?

    Jun Cao74 said:

    1. C5535 DSP UART can work on 236308 baud (not over its limit)

    236308 baud is not over the limit.
    The UART switching characteristics in the datasheet for UART TX show a max frequency of 6.25MHz (CVDD = 1.3V, 15/30 pF)
    I have successfully run UART with a virtual com port console at 921600 (Max rate supported by Tera Term)

    I also checked that CLKIN of 16.384MHz does not violate the PLL limits that are used by the bootloader during UART/USB boot.
    With 16.384MHz, and CLKIN = 1, the bootloader configures the SYSCLK to 49.152MHz (instead of 36MHz with 12MHZ CLKIN)
        PLL_CNTL1 (IOaddress=0x1C20) =    0x84AC
        PLL_CNTL2 (IOaddress=0x1C21) =    0x00C4
        PLL_CNTL3 (IOaddress=0x1C22) =    0x0806
        PLL_CNTL4 (IOaddress=0x1C23) =    0x0201
    With these settings, the C5535 bootloader can theoretically run with a CLKIN upto 20MHz without violating the max VCP output frequency of 120MHz (assumes 20MHz exactly without any error) - With 20MHz CLKIN, SYSCLK = 60MHz

    Jun Cao74 said:

    2. Changing DLL does not require reset – restart UART

    This requires some experimentation. The TRM procedure and CSL examples put the UART Transmitter and Receiver in reset with the PWREMU_MGMT register before altering the baud rate... And they are released from reset as the last step, but that will not work during a UART boot as no more reg_config data will be received from the host to take the UART pins out of reset... It would then be stuck.
    If changing the baud rate without putting the Transmitter and Receiver in reset fails, then you will not be able to proceed with this approach.

    Jun Cao74 said:

    3. The Host having longer delay than DSP delay will not cause problem, since boot loader UART is waiting for “START bit”.

    I am hoping that the bootloader can continue running at the faster baud rate, but the exact timing and amount of delay need to be experimented with. Like you say, it should wait for a START bit.


    Do you have an oscilloscope to capture the baud rate change? Maybe you could experiment with the CSL example first - performing UART transmits to observe how long it takes to change baud rates between consecutive transmits, and if the UART peripheral allows you to change baud rates without holding the Transmitter and Receiver in reset...

    Do let us know your results.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 100 points

    Mark:

    Thank you again for your great help.  I am on vacation will be back to work next week.

    1. Previous I used hex55.exe utility to build boot image but did not set the registers and time delay.  Based on your instructions, yesterday I just figured out the boot image but did not really build it.
    2. Great news - C5535 DSP UART can work on 236308 baud.  You even successfully run UART at 921600.  Can I further change DLL from 0x0D to 3 to set baud rate to (236308 * 13 / 3)?  I do not familiar with PLL (The Phase Loop Lock?).  Does it need HW support?  Our DSP board does not use PLL.
    3. As you suggested, I will first experiment the baud rate change during the run with DSP CSL example as UART receiver – Host UART transmitter.  I will definitely let you know the results.

    Best regards,

    Jun Cao

  • 0 in reply to Jun Cao74
    TI__Mastermind 30170 points

    Hi Jun Cao,

    Thanks for letting us know that the UART boot baud rate change worked.

    For debugging with CCS, you can see the state of the bootloader by checking the Program Counter register. You must connect to the target without a GEL file since the GEL file resets the DSP, clearing all registers. The program counter while executing from the ROM bootloader, will begin with 0xFF (refer to attached map file).

    You may also get boot status indication out of the XF pin and CLKOUT pin - try probing these signals during boot.

    I wonder if you are getting stuck in the MMC/SD boot while polling the peripherals. I have found that if you do not have a pull-up on MMC/SD CMD line, that it can sometimes get stuck waiting for a response from an SD card... even if there is no card present - the CMD line must be high to bypass MMC/SD boot.

    Once in the UART boot, you can also use regconfig to set a GPIO to use as status indication.

    /cfs-file/__key/communityserver-discussions-components-files/791/8080.Bootloader_5F00_R04.map

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 100 points
    Mark:
    Thank you very much for the information and always teach me things new. I have new questions, maybe I should or you can help to start it as new topic.
    1. How to connect the target without a GEL file?
    2. In our previous project, we use CCS4 V4.2.2.00033 and Blackhawk XDS560 Emulator to debug our board. Our license has expired. Now TI announced to provide CCS for free (do not need the license). How does it work? Though TI has many newer version of CCS, using CCS4 V4.2.2.00033 is easier for us especially we still use eZdsp5535 Kit and the SW. Can we just use eZdsp5535 Kit provided CCS to work with Blackhawk XDS560 Emulator to debug our board (previous we have to provide license to work with Emulator)?
    Thanks!
    Jun
  • 0 in reply to Jun Cao74
    TI__Mastermind 30170 points

    Hi Jun Cao,

    1. Refer to this E2E post for connecting without a GEL file: http://e2e.ti.com/support/dsp/c5000/f/109/p/558742/2055436#2055436

    2. As far as the CCS licensing goes, refer to this E2E post:

    If you want to stay on CCSv4, you might consider extending the 30 day license to a 90 day license to buy some time - so you can use the BlackHawk emulator.

    CCSv6 has a very similar look and feel as CCSv4. It will require you to upgrade your workspace, but old CCSv4 projects still open and build (as far as I know). You may want to download the older code gen tools that you are currently using to avoid any unexpected changes.

    I would search and then post on the CCS E2E forum (https://e2e.ti.com/support/development_tools/code_composer_studio/f/81) to see if you can use the Blackhawk for free with the new free license. I will also try to find out since I am not certain myself.

    This link seems to indicate you can use CCS for free with any emulator: http://processors.wiki.ti.com/index.php/Licensing_-_CCSv6

    This post, however, indicates that you still need a license to use the BlackHawk USB Emulator: https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/552206/2018255#2018255

    You can install CCSv6 beside CCSv4 and switch between them. I would create new workspaces for CCSv6 to avoid corrupting CCSv4 workspaces.

    I expect CCSv6 would come with a trial license, but you should download the CCSv6 free license and try to use the BlackHawk.

    Let me know if you give it a try.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 100 points
    Mark:
    This would be very important to us when our two CPU (one is C5535 DSP) development board is ready. I also remember, initially (about 3 years ago) we have some difficulty to use BlackHawk USB Emulator. At that time we have the CCSV5, but it could not work with BlackHawk USB Emulator. Once you find or post the related document, please let me know.
    Thanks a lot!
    Jun
  • 0 in reply to Jun Cao74
    TI__Mastermind 30170 points

    Hi Jun Cao,

    Good news! It looks like you can continue using CCSv4 with the Black Hawk on your custom board for free.

    See http://processors.wiki.ti.com/index.php/Download_CCS#Free_license_for_older_versions

    "With the release of CCSv7 all previous v4, v5 and v6 releases are free of charge. Simply unzip and copy the License File for Older versions into <install dir>/ccs_base/DebugServer/license or point CCS to its location when prompted."

    You just need the BlackHawk drivers, which can be installed when installing CCS (or after it has been installed). We can start a new thread in emulators E2E forum to get that working if you have difficulty.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 100 points
    Mark:
    Great! I got the License File and put it in ..\ccsv4\DebugServer\license\ccslicense.lic. I will start new thread in emulators E2E forum when I get the development board.
    Your great help comes so quick.
    Thank you very much!
    Jun