AM5706: Flashing Custom Board with Uniflash

Hi Joe,

Joseph Ott said:

Pausing the program in CCS it seems to be stuck in Board_moduleClockInit() at idkAM571x_clock.c:162 0x40332990

Can you please check exactly which operation is failing in Board_moduleClockInit?

Joseph Ott said:

dslite.bat --mode load --config=C:\Users\jott\ti\CCSTargetConfigurations\PcieCanCardAM5706.ccxml -f C:\ti\uniflash_8.2.0\processors\FlashWriter\idkAM571x\uart_idkAM571x_flash_programmer.out -n 4

Also, is there any change with respect to DDR in custom board?

Regards,
Parth

Parth Nagpal said:

Joseph Ott said:

Pausing the program in CCS it seems to be stuck in Board_moduleClockInit() at idkAM571x_clock.c:162 0x40332990

Can you please check exactly which operation is failing in Board_moduleClockInit?

When I paused the program in CCS there was no source listing only Assembler. Best I can tell from the assembler it was checking bit 0x100 in register 0x4A00 9100 which from the TRM is the CM_DSS_CLKSTCTRL register and bit 0x100 is the CLKACTIVITY_DSS_L3_GICLK.

Using the memory browser memory location 0x4A009100 shows the value 0x0000 0002

Parth Nagpal said:

Also, is there any change with respect to DDR in custom board?

Our custom board uses the same DRAM part as the devkit including the speed grade.  There are 2 differences:

1) The custom board uses a single DRAM device, not 2 like the devkit.  So only D0-D15 are used, D16-D31 and the corresponding strobes/masks are not connected.

2) Our custom board does not have an addition DRAM device to support sideband ECC.  I do not believe the AM5706 supports this anyway, unless the pins are a secondary function muxed with something else.

Joe

Parth,

Any answers on this yet? It is holding up delivery to customer.

Joe

Hi Joe,

Apologies for delay in response.

Joseph Ott said:

remove all gel files

Why are you removing the gel files while loading the application?

Joseph Ott said:

Pausing the program in CCS it seems to be stuck in Board_moduleClockInit() at idkAM571x_clock.c:162 0x40332990

Can you please build this in debug mode and then single step to see where exactly the issue is occurring?

Joseph Ott said:

The custom board uses a single DRAM device, not 2 like the devkit.  So only D0-D15 are used, D16-D31 and the corresponding strobes/masks are not connected.

What the size of DDR in your custom board. Can you also check the map file generated and confirm if the all the sections are fitting into the available DDR memory?

Regards,
Parth

Parth

Parth Nagpal said:

Why are you removing the gel files while loading the application

I attempting to erase the flash following the instructions found in this Post

Parth Nagpal said:

What the size of DDR in your custom board. Can you also check the map file generated and confirm if the all the sections are fitting into the available DDR memory?

Looking at the map file the program is loaded into OCM starting at 0x40300000

Parth Nagpal said:

Can you please build this in debug mode and then single step to see where exactly the issue is occurring?

I was initially looking for the source under eth UniFalsh install. I found what appears to be the source under C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash.

Is the code in C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash the code I need to be compiling and running to interact with the Uniflash command line?

I was able to compile the code under C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils and when I run that it stays in UFP_xModemHeaderReceive() which seems to indicate that it is waiting for an image from Uniflash 

 Using the following command to initial a download I didn't see the program exit the UFP_xModemHeaderReceive()  nor did it appear to receive any bytes. 

dslite.bat --mode processors -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0

The uniflash output seems to indicate that 

C:\ti\uniflash_8.2.0>dslite.bat --mode processors -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0
Executing the following command:
> C:\ti\uniflash_8.2.0\processors\ProcessorSDKSerialFlash.exe -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0

For more details and examples, please refer to the UniFlash Quick Start guide.


----------------------------------------------------------------------------
ProcessorSDKSerialFlash CLI Tool
Copyright (C) 2017-2023 Texas Instruments Incorporated - http://www.ti.com/
Version 1.8.0.0
----------------------------------------------------------------------------
Transferring the Image to Flash Programmer..

I should note that after running the program I did not see any 'C' being printed to a serial port as we did when using the Dev kit. Looking at the source code I didn't see any place where it was outputting a 'C'

We are using UART3 as the debug port same UART as the Uniflash talked to for the dev kit. Other programs running on the custom board using the UART LLD work fine.

Can you answer my question above?

Any further suggestions?

Joe

Hi Joe,

Sorry I am a little confused. Are you able to load the flash programmer now properly? Earlier, even that was failing right? What changes did you do to make it work?

Regards,
Parth

Yes I am able to load the flash programmer. It turned out that the core selection when loading the flash programmer  -n 4 was wrong it should be -n 3. 

When using the flash programmer binary that came with the UniFlash installation, it gets hung up in board config trying to read the EEPROM which our custom board does not have.

I found what appears to be the source code for the flash programmer under C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash.

After compiling this for our custom board I did not see any output on any UARTs. 

Looking at the source code for the flash programmer in C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash I did not see any code that would output the character 'C' to the UART.

Our board uses UART3 as the debug port, but also has UART1 and UART2 available.

Loading the flash programmer via CCS debug session I can see that it is waiting for a Xmodem transfer. 

I tried using the Uniflash command line

dslite.bat --mode processors -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0

to download the SBL but the dslite command seemed to be stuck transferring the image.

C:\ti\uniflash_8.2.0>dslite.bat --mode processors -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0
Executing the following command:
> C:\ti\uniflash_8.2.0\processors\ProcessorSDKSerialFlash.exe -c COM12 -f C:\ti\uniflash_8.2.0\Binaries\MLO -d 2 -i 1 -o 0

For more details and examples, please refer to the UniFlash Quick Start guide.


----------------------------------------------------------------------------
ProcessorSDKSerialFlash CLI Tool
Copyright (C) 2017-2023 Texas Instruments Incorporated - http://www.ti.com/
Version 1.8.0.0
----------------------------------------------------------------------------
Transferring the Image to Flash Programmer..

Is the code in C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash the code I need to be compiling and running to interact with the Uniflash command line? It does not seem to do the same as the flash programmer found in the uniflash install.

Hi Joe,

Joseph Ott said:

Is the code in C:\ti\processor_sdk_rtos_am57xx_08_01_00_09\pdk_am57xx_1_0_19\packages\ti\board\utils\uniflash the code I need to be compiling and running to interact with the Uniflash command line? It does not seem to do the same as the flash programmer found in the uniflash install.

Yes, that's the correct code. The Uniflash and PDK release does not go hand in hand. There might be some code differences in code.

Also, I just checked, looks like there was some issue with Uniflash latest version. You can modify the flash programmer according to your board needs and it built with SDK with the uniflash 6.3.

Regards,
Parth