AM6548: Uniflash error with FlashWriter programmed through CCS

Hi Hata,

I  suppose this is related to your earlier post here? https://e2e.ti.com/support/processors/f/791/t/848529

In the list of steps I had given that I tried out I did not disconnect and reconnect the UART interface. Honestly I'm a bit surprised to see this as part of the official steps, this seems more of a workaround to some issue that was seen on some(?) machines than how a serial port should be used. Also while it may work the recommendation of observing the UART with a terminal program while accessing it through dslite does not sound like a good idea to me neither so I wonder if the recommendation of disconnecting has something to do with this directly.

As I said I had no need to disconnect the serial port, and I also did not use the console and had no trouble using UniFlash. Which version of UniFlash are you using? I had used version v5.1.0 on a Windows 10 machine.

HaTa said:

Q2: Why re-connection of J42 is required?

Q3: Could you modify dslite to be able to run dslite without reconnecting J42?

I need to do some research internally on this, please give me a day or two. If you see this issue with version v5.1.0 (or later) I would agree that this is something we should be addressing, it does not make for a good experience during production.

Regards, Andreas

Hi Andreas,

>Which version of UniFlash are you using?

HostPC: Windows10 64bit (version 1903)

USB Serial Port Driver Provider : FTDI (Version:2.1.2.28.0)

Uniflash: v5.1.0

Tera Term: v4.104(SVN#8043)

Thanks and Best regards,

HaTa.

Hi HaTa,

thanks for the detail, I'll cross-check that against my own setup. Please allow until Monday while I am researching what could be going wrong here while trying to re-create the issue you are seeing.

Regards, Andreas

Hi HaTa,

so I just tried re-creating your setup of loading the flash programmer from Uniflash v5.1.0 via Code Composer Studio (rather than via the ROM bootloader, as already demonstrated working in https://e2e.ti.com/support/processors/f/791/t/848529) and also here I can use dslite.bat to access the Flash programmer firmware without issues once programmed via CCS, even without disconnecting/reconnecting J42 or using a terminal program as part of my flow. Note that I used the flashloader that comes with UniFlash and for that I had to use the R5 core to load it via CCS, and MCU_UART0 (rather than A53 and MAIN_UART0 as in the TI RTOS SDK documentation, which seems incorrect).

HaTa said:

I'd like to know the reason why above re-connection of J42 is required.

The error message if I execute "dslite" with the serial console open and without re-connection of J42 is,

       Couldn't Open Serial Port!

The error message if I execute "dslite" with the serial console close and without re-connection of J42 is,

       Failure:Unknown response from target! Please check the connection!

Failure:Unknown response from target! Please check the connection!” mean?

The first error is expected, as if the serial port is held open by some other software, the dslite-based programming tool can't access it.

Then, I had a look at the source code for the Windows Flasher program that gets invoked by dslite (ProcessorSDKSerialFlash.cpp, this code is also delivered as part of the RTOS SDK, albeit in a different version than what comes with Uniflash v5.1.0) and the "Unknown response from target" error would get emitted when the code is receiving a bunch of unexpected data or garbage. The qu

HaTa said:

Q2: Why re-connection of J42 is required?

It might be that the process of disconnecting/reconnecting J42 acts as a workaround of flushing out any extra data to be able to have a clean start communicating with the flash loader firmware. You could try the following to see this helps your case.

1. Use CCS to program the Flashloader firmware
2. Leave J42 connected at all times
3. Before attempting to use dslite.bat, try flushing the UART receive chain by issuing the following commands (update for your respective COMx). Basically, read a few seconds worth of data into the console. Then, abort using CTRL+C.

C:\ti\uniflash_5.1.0>mode COM4 BAUD=115100 PARITY=n DATA=8

Status for device COM4:
-----------------------
    Baud:            115100
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        ON
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     OFF


C:\ti\uniflash_5.1.0>type COM4
CCCCThe I/O operation has been aborted because of either a thread exit or an application request.

4. Now use dslite.bat to perform operation on the target device

As an alternative, you could also try to open a terminal program, witness the 'C's being received, close it, and then proceed to using dslite.bat. Also all without disconnecting J42.

HaTa said:

Q3: Could you modify dslite to be able to run dslite without reconnecting J42?

In order to fix/improve the code I'd like to be able to re-create the issue here locally first, which so far I have not been. Running the above experiments on your end might give us a better idea what the cause could be however.

Also, have you tried these steps on different PCs, and making changes to your USB setup (different USB port, removal of any USB hub(s) in the chain to the AM654x EVM, etc.). I wonder if you can recreate the issue consistently on different setups.

Lastly, why do you want to use CCS to load the flash programmer, rather than ROM-based UART boot?

Regards, Andreas

Hi Andreas,

I tried to do with your procedures, however , the command "type" outputs the error message "The system cannot find the file specified."

At least, my customer and I am facing same error message.

And now, we are using AM65x ROM bootloader to flash the program instead of using CCS.

The procedure what I did :

1)  SW3.2=SW3.4=ON, all other SW3.x off. All SW2.x off

2)  Power on EVM

3)  Open the terminal window "Tera Term" and connect to UART

4)  Confirm that AM65x boot loader prints the character "CCCC"

5)  Close the tera term window

6)  Don't do reconnection of J42

7) Open Window command prompt

8) execute the command "mode COM16 BAUD=115100 PARITY=n DATA=8"

9) execute the command "type COM16"

C:\ti\uniflash_5.1.0>mode COM16 BAUD=115100 PARITY=n DATA=8

Status for device COM16:
------------------------
    Baud:            115100
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     OFF


C:\ti\uniflash_5.1.0>type COM16
The system cannot find the file specified.

C:\ti\uniflash_5.1.0>

Is there any difference with your procedures?

Thanks and Best regards,

HaTa.

Hi Andreas,

I change the number of COM from 16 to 2 by device driver, and I can execute "type" now.

However, I still cannot execute "dslite" correctly.

But, if I use PuTTY instead of TeraTerm then I cannot can execute "dslite" correctly without re-connecting of J42!!

How do you end this problem?

Thanks and Best regards,

HaTa.

Hi HaTa,

HaTa said:

However, I still cannot execute "dslite" correctly.

But, if I use PuTTY instead of TeraTerm then I cannot execute "dslite" correctly without re-connecting of J42!!

Thanks for confirming this aspect. Can you try different PCs to see if you can consistently re-create the issues also on other setups as I suggested earlier?

Ultimately I'd like to find a way to witness these issues here locally so that I can potentially attempt fixing/improving the behavior and then verifying the fix.

Regards, Andreas