SK-AM62: Cannot Flash SOC Initialization Binary via Uniflash+UART "XMODEM Send Failed" & "Send Error: Expected ACK"

Hello,

Can you please share the output of Python script available in the following FAQ

[FAQ] [AM6XX]: How to check if device type is HS-SE, HS-FS or GP? - Processors forum - Processors - TI E2E support forums

Was just running that script when you posted the question, here are the results (GP):

CAMERON MANN said:

Was just running that script when you posted the question, here are the results (GP):

You are using the GP images (*.release.tiimage) which are expected for GP devices so this is not the issue of using wrong images.

CAMERON MANN said:

Despite the errors above, I am receiving a "healthy" stream of "C" chars in the CCS terminal using the same COM port connection

Did you try performing the flashing procedure again after it fails?

Yes, I retried the flash procedure after it failed (with no power-cycle), and I have also retried the flash procedure after a power cycle (and ~1 minute delay). Both of those procedures resulted in the same outcome, no successful flash. 

Quick update with some positive news: I pursued an alternate SOC initialization step as recommended in the EVM setup guide. I copied the Debian RT image to an SD card, loaded that into the board, then followed the "SOC Initialization Using SPL" instructions. Linux booted as expected, and I could see the M4 core started as expected. I was also able to see the startup messages from the M4 core via the UART terminal in CCS. Once I saw this, I proceeded to follow the "Build Hello World example" and "CCS Launch, Load and Run" steps. After following those steps, I was able to successfully run the Hello World FreeRTOS example and see the expected output in the xds110 and UART console.

So, it appears after this test my toolchain and board are healthy as best I can tell. I am still at a loss as to why the UART flash process is failing. Perhaps there is a way to flash from inside the Debian OS? 

Hello,

CAMERON MANN said:

I have also retried the flash procedure after a power cycle (and ~1 minute delay).

This might trigger the timeout resulting in the failure. You should start the UART flashing procedure as soon as the board is powered on. I believe in that case you should not see any failure.

I attempted that procedure several times with no success. I made several attempts, immediately after power-up, 2 to 3 second delays, etc but no more than 5 seconds or so. I really thought that might work and I appreciate the idea regardless, it was a good try. I did perform some "investigation" into what may be programmed onto my board's memory: I attempted to boot from NOR, NAND, and eMMC while monitoring the serial console for activity, but I saw none. I specifically started with the OSPI NOR mode to see if there was a NULL bootloader already there. I saw no activity at all. Again the only success I have had initializing the SOC is via SD boot+linux (and that worked great). 

Is there a process documented to flash this board via the Uniflash GUI tool? I am new to that tool so I am not sure if I would be wasting my time trying to debug further using that tool versus the command line flash utility.

CAMERON MANN said:

I attempted that procedure several times with no success. I made several attempts, immediately after power-up, 2 to 3 second delays, etc but no more than 5 seconds or so.

This is unexpected. I have seen the UART Uniflash failures in the past. But that always resolved after resetting the board and immediately starting the flashing procedure.

May I know the SDK version you are using? Please note, we aren't testing the SDKs from v9.0 onwards on GP devices (which you are using) in an effort to have the default support for secure devices (HSFS/HSSE) only.

So, if you are using v9.x, can you please try out the SDK v8.6 which last supported the GP devices.

Additionally, you can also try booting the `sbl_uart_uniflash_stage1.release.tiimage` alone using Teraterm. Simply send the image using XMODEM as shown

If this gets sent successfully, comment the `--flash-writer` line in .cfg file and start the flashing procedure for the rest of the images.

CAMERON MANN said:

Is there a process documented to flash this board via the Uniflash GUI tool?

This will not do any good. The GUI tool is not actively maintained or tested.

After careful consideration I decided to move to a different SoC for my project, partially due to the issues related above, and performance considerations. As such I did not pursue the proposed solution leveraging the v8.6 SDK. I appreciate the assistance I received. Apologies for the delay in my response.