TMDSIDK437X: Flashing via UART

Hi Liliane,

The RTOS SDK guide states that the AM437x IDK UART boot is not supported, but AM437x GP EVM does support UART boot. Since you have saw the CCC... on the UART after your board changes. It means the UART boot may be supported on AM437x IDK. The question is which BIN file you sent via UART.

You should have loaded the pdk_am437x_1_0_16\packages\ti\starterware\binary\bootloader\bin\am43xx-evm\gcc\bootloader_boot_uart_a9host_debug.bin (not the bootloader_boot_uart_a9host_debug_ti.bin or others).

If it still no display on UART, you can connect to A9 core via JTAG and then load the symbols from bootloader_boot_uart_a9host_debug.out, so that you can see where the code is stuck (ROM code or SBL code).

Ming

Hello Ming,

Thank you for your prompt response.

I tried to flash the SBL on both the iceamic110 and the idk am437x.

This is what happened with the iceamic110:

I am sure that I loaded the right binary as you said. On top of that, I ran the SBL by connecting to the core via JTAG and loading the program, and there is no problem with running the code, I also see the expected console outputs. When the code asks for the application file, I intentionally sent the bootloader via XMODEM and managed to successfully run it again. To me, this is an indicator that the problem is neither in the SBL, nor in the transfer of the binary via XMODEM, but in the ROM bootloader. However, when I just load the symbols and try to send the SBL directly via XMODEM (transfer is successful), again nothing happens. According to my best understanding, this shows that the SBL code never starts.

Now my question is, if there is any chance to debug the ROM bootloader? Since I see the expected CCCCC sequence, I assume that I am in the right booting mode. Also, if I change the control module status register to a configuration where UART0 booting is not supported, the sequence does not show up anymore and a file transfer via xmodem is not successful. At this point of time, I am confused about which part is missing/causing the problem. Can it be that the timeout is exceeded when sending the binary and the mpu goes into a dead loop? Anyhow, if this would be the case, I can't understand why I can again send the bootloader (if it would be a dead loop, in my opinion, the transfer should not be successful anymore...)

This is what happened with the idkam437x:
The CCC sequence shows up, and I can successfully transfer the ..._debug.bin file via xmodem, but again, nothing happens. As soon as the file transfer starts, the motor fault LED turns on.
In the case of this board, I was not able to load the .out file onto the target (Trouble writing memory block at 0x402f0074 on page 0 of length 0x7ff0: (Error -1065 @ 0x3D5A) Unable to access device memory. Verify that memory address is in valid memory.

As a first step, I would like to get the UART booting process running on the amic110. Then I would like to investigate what is happening on the AM437x. Understanding where the error lies is crucial for the design of our custom board. I am again thankful for any hints or advice.

Best,

Liliane

Hi Liliane,

I am a little bit confused on why you wanted to make iceamic110 to work first. The AMIC110 is a variant of AM335x, while idkam437x is using AM437x.

In case you still want to make the iceamic110, make sure you use the correct bin file (bootloader_boot_uart_a8host_debug.bin) under pdk_am335x_1_0_16\packages\ti\starterware\binary\bootloader\bin\am335x-evm\gcc.

I know for sure the iceamic110 UART boot is working, because I tried it before. It worked as expected. 

As I mentioned in previous post, to debug the problem you are facing, the first thing to do is that to determine where the code is stuck at, RON bootloader or SBL. The steps are as follows:

1. Power up the board, use UART to feed the SBL to the ROM bootloader

2. If it stuck somewhere (no display on UART), then use JTAG (using a ccxml without gel file for A9 or A8) to connect to A9 (or A8) and halt the CPU

3. Load Symbol (not the program) from the corresponding OUT file

4. If the stack is preserved, then you can tell from the stack view where your program is stuck at. You may be able to tell the problem is from the SBL or the ROM bootloader.

Ming

Hi Ming,

It turns out that the bootloader on AMIC110 was working. Though it did not print anything to the console, it was possible to load a second file via xmodem that then was successfully loaded. Anyhow I am kind of confused why the prints are not working (only in the case of the SBL, after loading the app, the prints work).

In the case of the AM437x, I found that the code is stuck at 0x3008X which is the data abort exception handler according to the TRM, and it is supposed to indicate problems with accessing memory locations (read/write). Unfortunately, the code is of course stuck in a dead loop upon reaching the dead loop.
Do you have any clue what is going on and what the connection between the MOTOR fault LED and the bootconfiguration[4:0] 11001 is?
I see that UART0 boot is supported on the GP EVM (but I don't have on in house), and I wonder why I cannot make it work on the IDK. I also tried different boot configurations that should support UART0, but none of them seem to work. I am really thankful for any further help.

Best,

Liliane

Hi Ming,

I looked into the hardware difference between the GP EVM and the IDK, and the sysboot pins 0:4 go the same pins on the AM437x.

The only difference is that on the GP EVM, the pins are used as DSS_DATA (and can be switched between high and low), while on the IDK they are used for the Ethernet (TX_CLK, TX_EN, TXD3:1), however I don't believe that this poses a problem since on the ICEAMIC110, these pins are also used for the Ethernet, and there the UART booting works. As much as I understood, the values of the sysboot pins get latched on PORz, and then the pins can be used for different purposes. On both the ICEAMIC110 and IDKAM437X, this switching is realized via SN74LV buffer. The only difference that I found is that the OE# pin of the buffer is connected to the PORZn on the IDK, meaning that the only situation where the buffer is on and the sysboot values get transferred to the core are when a reset is triggered. On the ICEAMIC110 however, the OE# pin is connected to MII_RXD2. I don't really believe that the issue is stemming from there though.
Right now, I assume that there is a software issue, but I am happy if you have any further advice.

Best,
Liliane

Hi Liliane,

I just did a comparison between the board library for evmAM437x and idkAM437x. Between

L:\ti_am4_610\pdk_am437x_1_0_16\packages\ti\board\src\evmAM437x\include\board_cfg.h and

L:\ti_am4_610\pdk_am437x_1_0_16\packages\ti\board\src\idkAM437x\include\board_cfg.h

BOARD_DDR3_SIZE is different (2GB vs 1GB)

There are many other differences between those two boards. It is hard to find out which difference actually caused the problem.

Can you try to load the ti_am4_610\pdk_am437x_1_0_16\packages\ti\starterware\binary\bootloader\bin\am43xx-evm\gcc\bootloader_boot_uart_a9host_debug.out with JTAG and run it on the idkAM437x, so that you can pin out where it stuck at.

Ming

Hi Ming,

Just wanted to let you know that I managed to solve the problem. I adapted the SBL to support our custom board and these changes actually made the UART flashing work. It is hard to say what made the difference. Another issue when debugging was that I tried to use the USB with integrated debug probe for both the UART and JTAG function at the same time. When using a separate XDS200 debug probe, everything worked perfectly.

Thank you and best,

Liliane